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1.0  INTRODUCTION 


In  the  Fall  of  1974  the  Data  Processing  Directorate  of  the  Ballistic 
Missile  Defense  Advanced  Technology  Center  (BMDATC)  initiated  a series  of 
research  programs  directed  to  the  development  of  a complete  and  unified 
approach  to  software  development.  These  programs  encompassed  the  total 
range  of  activities  from  development  of  system  specifications  through 
completion  and  testing  of  the  software  process  design.  Supporting  programs 
were  also  conducted  to  perform  basic  research  into  such  areas  as  software 
reliability,  static  and  dynamic  validation  techniques,  and  adaptive  control 
and  learning. 

A key  element  of  the  BMDATC  programs  was  the  Software  Requirements 
Engineering  Program  (SREP)  --  a research  effort  concerned  with  a systematic 
approach  to  the  development  of  complete  and  validated  software  requirements 
specifications.  The  overall  objectives  of  this  research  were  to: 

• Ensure  a well-defined  technique  for  decomposition  of  system 
requirements  into  structured  software  requirements. 

• Provide  a mechanism  for  enhanced  management  visibility  into 
the  requirements  development. 

• Maintain  requirements  development  independent  of  the  target 
machine  and  the  eventual  software  design. 

• Allow  for  easy  response  to  system  requirement  changes. 

t Provide  for  testable  and  easily  validated  software  require- 
ments . 

To  meet  these  objectives,  the  Software  Requirements  Engineering 
Methodology  (SREM)  was  developed.  This  methodology  is  an  integrated, 
structured  approach  to  requirements  engineering  activities.  SREM  begins  with 
the  translation  and  decomposition  of  system  level  requirements;  performs 
analysis,  definition,  and  validation  of  the  software  requirements;  and  ends 
with  documentation  of  the  software  requirements  in  a Process  Performance 
Requirements  (PPR)  specification.  As  part  of  the  SRE  methodology,  a set  of 
software  support  tools  were  implemented  to  automate  many  of  the  previously 
manual  activities  associated  with  requirements  engineering.  These  software 
tools  form  the  Requirements  Engineering  and  Validation  System  (REVS);  REVS 
processing  is  accomplished  by  expression  of  the  software  requirements  in  the 
structured,  formal  Requirements  Specification  Language  (RSL). 
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SREM  represents  a different  approach  and  philosophy  for  software 
requirements  engineering.  It  embodies  a flow  orientation  that  eliminates 
many  of  the  problems  inherent  in  the  classical  functional  hierarchy.  It 
expresses  requirements  in  an  unambiguous,  machine-processable  language  as 
opposed  to  free  form  (and  free  content)  English.  Support  software  is 
available  to  automatically  process  the  requirements  statements  and  perform 
a wide  range  of  needed  activities  (e.g.,  static  flow  analysis,  specification 
generation,  simulation  generation). 

SREM  is  a comprehensive  approach  that  was  developed  specifically  to 
improve  software  requirements  engineering  practices.  As  shown  in  Figure 
1-1,  errors  made  in  the  requirements  phase  become  increasingly  more 
expensive  to  locate  and  correct  in  the  later  phases  of  development. 


Figure  1-1  The  Cost  of  Delayed  Error  Detection 


Ambiguity  and  lack  of  preciseness  in  the  requirements  statements  which 
indirectly  promote  misinterpretation  (and  therefore  errors)  In  the  subse- 
quent phases  also  add  to  the  cost  and  schedule  leverage. 
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1.1  SCOPE  AND  CONTENT 


This  report  is  a SREM  User's  Guide  for  development  of  software 
requirements  specifications.  It  is  not  a cookbook,  in  that  it  does  not 
attempt  the  inherently  impossible  task  of  converting  the  genuinely  creative 
aspects  of  specification  development  into  rote,  deductive  operations.  It 
does,  however,  define  guidelines  through  which  these  creative  operations 
are  recognized,  applied  and  restricted  to  their  natural  roles  in  the 
specification  development  process.  In  this  manner,  the  scale  and  range  of 
creativity  can  be  defined  and  contained,  thus  allowing  the  specification 
development  process  to  be  scheduled  with  some  degree  of  confidence.  It 
should  be  noted  that  creative  features  remain  in  the  methodology  and  as  a 
consequence  the  major  development  effort  must  be  conducted  by  experienced, 
knowledgable  engineers.  However,  SREM  has  been  structured  in  a manner  such 
that  many  elements  of  specification  development  can  be  identified  and 
isolated  to  permit  less  senior  engineering  personnel  to  perform  the  details 
of  specification  statement  definition  and  documentation  preparation. 

This  volume  is  organized  in  two  major  parts:  Part  I addresses  the 
technical  aspects  of  software  requirements  engineering.  The  methodology 
is  described  in  detail,  step-by-step,  in  the  context  of  a representative 
example.  Part  II  discusses  the  management  of  the  specification  development 
process  with  emphasis  on  how  the  specific  features  of  SREM  and  its  tools 
can  be  used  to  advantage  in  the  management  of  the  activities. 

The  remainder  of  this  section  describes  the  basic  role  of  SREM,  its 
major  components  and  its  position  within  the  overall  BMDATC  software 
development  methodology. 
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1.2  the  planned  role  of  srem 


SREM  was  conceived  of,  and  designed  as,  an  integral  part  of  the 
BMDATC  Software  Development  Methodology.  The  objective  of  the  overall 
BMDATC  methodology  was  to  further  the  state-of-the-art  in  the  specification, 
design,  implementation  and  test  of  real-time  BMD  software.  Its  applica- 
tion was  targeted  to  systems  whose  major  characteristics  and  development 
environments  are  as  follows: 

System  Characteristics 

• Systems  are  large  to  very  large 
0 Time  responses  are  critical 

• Processing  is  intensive 

• Data  base  is  large  but  not  massive 

• Computer  system  is  digital  with  memory 

0 Technology  of  the  object  system  is  not  fully  understood 
initially  (i.e.,  existence  and  feasibility  of  the  system 
and  subsystems  is  an  issue) 

0 Requirements  may  be  subject  to  a high  degree  of  change 

• Subsystems  interfacing  with  the  DP  may  (probably)  be 
undergoing  parallel  development  (i.e.,  interfaces  are 
flexible). 

Range  of  System  Development  Environments 

0 From  a deployable  system  being  developed  essentially  top- 
down  from  system  performance  objectives,  which  must  deal 
wi  th: 

Hard  performance  requirements. 

Firm  threat  definition. 

Strong  top-level  configuration  control, 

Slow  change  control , 

Maximum  design  freedom,  and 

Cost  and  schedule  as  major  considerations. 
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• To  an  R&D  project  where  design  decisions  are  influenced  by 
objectives  of  investigating  specific  approaches  (e.g., 
improvement  of  the  state-of-the-art)  which  must  deal  with 

Minimum  performance  requirements. 

Flexible  threat. 

Less-formal  configuration  control, 

Reduced  design  freedom,  and 

Cost  and  schedule  of  lesser  importance. 

The  range  of  activities  which  are  addressed  by  SREM  requires  both  a 
knowledge  of  systems  engineering  and  of  data  processing  technology.  The 
starting  point  of  SREM  is  the  point  in  systems  engineering  when  the  system 
requirements  analysis  has  identified  the  functions  and  the  stress  points 
of  the  weapon  system;  the  interfaces  between  the  subsystems  (at  least  on 
the  functional  level);  top-level  weapon  system  functions  and  the  weapon 
system  operating  rules  (conditional  statements  impacting  when  and  in  what 
sequence  the  functions  are  performed);  and  the  top-level  weapon  system 
functions  that  have  been  allocated  to  the  data  processor. 

The  ending  point  of  SREM  is  reached  when  all  system  requirements 
allocated  to  the  data  processor  have  been  sufficiently  decomposed  into 
data  processor  terms  so  that  primarily  software  development  expertise  is 
required  to  continue.  The  DP  interfaces  have  been  determined  to  the 
element  level,  all  processing  steps  have  been  identified  with  appropriate 
DP  requirements  levied,  all  actions  of  the  DP  in  response  to  a stimulus 
are  determined  in  terms  of  sequences  of  processing  steps,  and  the 
processing  necessary  to  generate  all  required  DP  output  interface  messages 
has  been  specified. 
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1.3  CONSIDERATIONS  OF  SREM  DEVELOPMENT 


The  first  step  in  defining  the  Software  Requirements  Engineering 
Methodology  was  to  determine  the  properties  required  of  a specification 
and  of  the  individual  requirements  of  which  it  is  composed.  The  initial 
considerations  were  that: 

• A specification  is  the  set  of  all  requirements  which  must 
be  satisfied,  and  the  identification  of  the  subsets  which 
must  be  met  concurrently;  and 

• A specification  is  neither  realizable  nor  legally  binding 
unless  it  is  consistent  with  both  the  laws  of  logic  and 
the  laws  of  nature. 

In  addition 

t A specification  defines  the  properties  required  of  a product 
such  that  any  delivery  satisfying  the  specification  satisfies 
the  objectives  of  the  specifier. 

Taken  together,  the  above  consideration  lead  to  a set  of  properties  which 
a specification  must  have  from  a technical  point  of  view. 

• Internal  Consistency 

• Consistency  with  the  physical  universe 

• Freedom  from  ambiguity. 

Economic  and  management  considerations  lead  to  an  additional  set  of 
properties  which  a good  specification  must  exhibit: 

• Clarity 

• Minimality 

• Predictability  of  specification  development 

t Controllability  of  software  development. 

Since  freedom  from  ambiguity  was  mandatory,  a machine-readable  state- 
ment of  software  requirements  was  defined.  It  is  a known  principle  of 
computer  operation  that  input  ambiguities  can  be  tolerated  only  insofar 
as  they  are  designed  into  the  software.  Thus,  by  employing  an  unambiguous 
language,  and  by  translating  and  analyzing  it  with  a program  intolerant  of 
ambiguity,  a precise  statement  of  requirements  was  ensured. 
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To  provide  an  internally  consistent  specification,  analyses  of  the 
requirements  statements  are  incorporated  into  the  system  supporting  the 
language.  These  analyses  include  semantic  and  syntactic  decomposition  of 
the  individual  statements,  and  analysis  of  the  composite  flow  of  data  and 
processing.  Support  of  consistency  with  the  physical  universe  is  accom- 
plished by  converting  the  specification  unambiguously  into  a model 
(simulation)  which  can  be  executed  against  a model  of  the  real  world. 
Recently,  the  government  has  required  that  software  be  developed  in 
accordance  with  a new  standard,  5000.29.  One  key  aspect  of  the  new  require- 
ment is  that  any  software  specification  must  be  validated  before  being 
imposed.  With  the  collection  of  tools  and  the  methodology  for  their  use, 
SREM  provides  a means  for  that  validation  through  static  and  dynamic 
analysis  at  the  requirements  level. 

Finally,  to  support  control  of  both  the  specification  process  and 
software  development,  a means  of  selective  documentation  and  analysis  of 
the  specification  is  provided.  The  integration  of  these  tools  with  a 
sound  and  methodical  engineering  and  management  approach  provides  predict- 
ability in  the  specification  process  and  aids  in  avoiding  overspecification. 
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1.4  MAJOR  COMPONENTS  OF  SREM 

1.4.1  The  Requirements  Statement  Language  (RSL) 


The  Requirements  Statement  Language  is  a user-oriented  mechanism  for 
specifying  requirements.  It  is  oriented  heavily  toward  colloquial  English, 
and  uses  nouns  for  elements  and  attributes,  and  transitive  verbs  for  rela- 
tionships; a complementary  relationship  uses  the  passive  form  of  the  verb. 
Both  syntax  and  semantics  echo  English  usage,  so  that  many  simple  RSL 
sentences  may  be  read  as  English  with  the  same  meaning.  However,  the 
precision  of  RSL,  enforced  through  machine  translation,  is  not  typical 
of  colloquial  speech;  as  a result,  most  complex  RSL  sentences  are  a some- 
what stylized  form  of  English. 

RSL  is  an  extensible  language  in  that  certain  primitive  concepts  are 
initially  built  in  which  can  then,  in  turn,  be  used  to  define  additional 
complex  language  concepts.  The  primitives  are  elements,  attributes, 
relationships,  and  structures.  From  these,  a nucleus  of  concepts  has  been 
defined  which,  to  date,  has  proven  sufficient.  Future  users  of  the 
language  can  add  to  the  nucleus  by  means  of  the  extension  features  provided 
by  REVS. 

1.4.2  The  Requirements  Engineering  and  Validation  System  (REVS) 

REVS  is  an  integrated  set  of  tools  used  to  support  the  definition, 
analysis,  simulation,  and  documentation  of  software  requirements.  A key 
concept  of  REVS  is  that  all  requirements  are  translated  into  a central 
data  base  called  the  Abstract  System  Semantic  Model  (ASSM).  The  RSL 
statements  themselves  are  not  stored  in  the  ASSM.  Instead,  they  are 
translated  into  representations  of  the  information  content  of  the  require- 
ments statements.  This  provides  an  efficient  and  flexible  means  of  main- 
taining a large  software  specification  in  a relatively  small  computer 
data  base. 
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The  ASSM  is  a relational  data  base  providing  a common  source  for  all 
requirements  analysis,  modelling  and  for  documentation.  The  commonality 
of  all  data  ensures  that  any  combination  of  extractions  from  the  ASSM  at 
any  time  (e.g.,  a document  and  a simulation)  will  be  mutually  consistent. 
That  consistency  is  essential  to  assertinq  that  the  requirements  modelled 
in  validation  of  the  specification  are  equivalent  in  every  sense  to  those 
written  in  the  specification. 

REVS  provides  two  mechanisms  for  entry  of  data  into  the  ASSM,  trans- 
lation and  interactive  graphics,  and  a powerful  set  of  tools  for  analysis 
termed  collectively  Requirements  Analysis  and  Data  Extraction  (RADX). 
Translation  is  the  process  of  converting  RSL  statements  into  the  ASSM 
information,  where  the  source  of  the  statements  may  be  cards,  card  images 
on  tape,  or  keyboard  entry  from  a terminal.  Interactive  graphics  (RNETGEN) 
is  a software  package  executing  in  conjunction  with  the  Anagraph  color 
graphics  console  to  provide  ASSM  entry  and  illustrative  documentation. 

It  permits  entry  of  structures  and  referenced  elements  in  a manner  parallel 
with  the  translator,  and  in  fact  may  be  used  in  conjunction  with  translation 
in  an  operational  environment.  Significantly,  RNETGEN  allows  the  user  to 
attribute  graphical  information  to  his  structure,  both  for  multicolor 
display  on  the  Anagraph  and  for  documentation  via  CALCOMP. 

Information  held  in  the  ASSM  may  be  selected  and  output  using  RADX. 
That  tool  is  responsive  to  user  direction  in  selecting  either  a re-creation 
of  the  information  translated  into  the  ASSM,  or  the  formatted  abstraction 
of  that  information  in  a user-defined  HIERARCHY.  The  combination  of  these 
features  allows  complex  selections  to  be  effected,  so  that  all  information 
needed  for  documentation  and  much  that  is  essential  to  configuration  manage- 
ment can  be  abstracted  from  the  system  without  the  encumberance  of  irrele- 
vant data.  Since  all  data  abstractions  are  drawn  from  a common  ASSM  (and 
since  that  data  base  is  confirmably  consistent  within  itself),  even  redun- 
dant assertions  in  data  extractions  are  absolutely  consistent  with  one 
another. 

Both  static  and  dynamic  analysis  are  provided  by  REVS  in  order  to 
determine  the  internal  consistency  of  the  ASSM  and  its  validity  with 
respect  to  the  laws  of  nature.  Static  analysis  is  performed  in  RADX 
which  examines  the  data  connectivity  through  the  requirements  to  determine 
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that  the  laws  of  logic  and  the  conventions  of  the  language  are  fully 
satisfied  throughout.  Some  forms  of  completeness  testing  are  also  accom- 
plished, determining,  for  example,  that  constants  are  provided  as  required; 
the  scope  of  completeness  testing  is  largely  at  the  discretion  of  the  user, 
since  he  may  define  extensive  static  analyses  through  RADX  commands  to 
supplement  those  inherent  in  the  system. 

No  amount  of  static  testing  can  fully  validate  a set  of  requirements. 

To  do  so,  the  system  they  represent  must  be  exercised  against  a model  of 
the  environment  in  which  the  system  is  to  execute.  Such  simulations  are 
provided  by  an  automated  simulation  builder  (SIMGEN),  and  a software 
package  supporting  its  execution  (SIMXQT).  Two  different  levels  of  simu- 
lation are  supported:  analytic,  in  which  high-fidelity  models  of  the 
environment  and  explicit  performance  measures  are  provided,  and  functional, 
in  which  the  connectivity  of  the  system  is  validated  with  non-analytic  models. 

1.4.3  The  Engineering  Methodology 

Historically,  the  methods  for  developing  a software  specification 
have  been  as  numerous  as  the  developers  of  such  documents.  In  fact,  few 
cases  can  be  cited  in  which  any  formal  methodology  could  be  quoted.  Until 
the  specification  appeared  (often  after  tens  or  hundreds  of  man-years  of 
effort),  nothing  was  available  to  show  that  it  would  actually  be  generated. 

In  addition.  It  has  frequently  been  true  that  the  quality  of  the  specification 
even  with  respect  to  elementary  consistency  from  one  requirement  to  another, 
could  be  verified  only  very  late  in  software  development.  Since  the  prob- 
lems were  discovered  only  when  the  cost  of  correction  was  prohibitive,  the 
requirements  were  frequently  changed,  degrading  system  performance  in 
order  to  have  a 'workable'  product. 

The  methodology  developed  within  SREM  is  not  only  formal,  in  that  it 
provides  an  explicit  sequence  of  steps  leading  to  the  specification,  but 
also  manageable,  in  that  it  illuminates  multiple  phases  for  management 
review  and  analysis.  Along  the  way,  it  supports  early  detection  of  high- 
level  anomalies,  since  it  works  from  the  highest  levels  of  software  defi- 
nition (processing  and  data  flows)  to  the  most  detailed  (analytic  models 
and  data  content)  in  a systematic  manner.  A key  feature  of  SREM  is  that 
the  processing  functions  and  data  communications  are  considered  in  parallel. 
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rather  than  have  either  follow  the  other.  As  a result,  the  connectivity 
of  the  system  is  always  complete,  and  it  becomes  possible  to  partition  the 
requirements  effort  among  several  groups  early  in  the  process  without 
risking  divergence,  omissions,  or  inconsistencies. 


1.4.4  Specification  Management 


The  management  of  a specification  developed  under  SREM  benefits 
most  from  the  common  source  in  the  ASSM  for  all  representations  of  the 
requirements.  Thus,  the  simulation  of  the  specification  and  the  documen- 
tation of  its  requirements  must  be  consistent  at  any  time,  since  both 
have  a single  source  of  data  which  generate  each  without  human  inter- 
vention. In  addition  to  a common  data  base,  the  methodology  itself 
supports  an  orderly  development  which  can  be  annotated  with  milestones, 
recorded  on  PERT  charts,  and  otherwise  controlled  with  the  tools  of  the 
last  several  decades  to  provide  predictability  and  control.  This  is  not 
to  suggest  that  the  creativity  of  the  specification  process  can  either  be 
scheduled  or  bypassed;  it  is  still  needed,  but  the  methodology  isolates 
it  into  segments  with  high  visibility,  supporting  management  cognizance 
of  its  progress  and  impact. 
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1.5  APPLICABILITY 


These  tools  and  techniques  have  been  developed  to  address  the  needs 
of  BMD  software  development.  With  perhaps  minor  exceptions,  however, 

SREM  is  directly  applicable  to  the  specification  of  the  requirements  for 
any  central  software  process  for  a large  real-time  system.  In  fact, 
since  the  methodology  is  inherently  and  deliberately  computer  independent, 
the  techniques  are  not  limited  strictly  to  software  in  the  form  of  com- 
puter programs.  The  requirements  for  any  process  composed  of  logical 
decisions  and  computations  performed  on  data  can  be  expressed  via  SREM  -- 
regardless  of  whether  the  end  product  will  be  software,  hardware,  firm- 
ware, or  some  combination. 

1.6  TERMINOLOGY 

At  the  risk  of  introducing  confusion,  some  non-standard  terminology 
is  used  to  describe  certain  SREM  concepts.  This  has  been  done  for  two 
purposes:  (1)  to  emphasize  the  different  interpretations  given  to  selected 
concepts,  and  (2)  to  emphasize  the  generality  of  the  methodology  application. 
An  example  of  the  first  is  the  use  of  the  term  ALPHA  for  a processing  step. 
The  more  common  term  "function"  would  be  misleading  because  there  is,  in 
fact,  a wide  variety  of  common  interpretations  of  "function".  To  avoid 
misunderstanding,  a new,  unfamiliar  term  is  used  in  order  to  emphasize  its 
specific  meaning.  An  example  of  the  second  is  the  name  applied  to  the 
resulting  requirements  specification  which  is  called  the  Process  Performance 
Requirements  (PPR).  No  documentation  system  currently  recognizes  a document 
called  a PPR.  Here,  the  point  is  that  any  software  requirements  specifi- 
cation, whether  called  a B-5  (in  MIL-STD  490)  or  something  else  in  some 
other  system,  must  contain  a certain  set  of  information.  That  specific 
set  of  information  generated  via  SREM  has  been  named  a PPR.  The  same  con- 
siderations lead  to  a definition  of  the  originating  input  specifications  to 
SREM  as  the  Data  Processing  System  Performance  Requirements  (DPSPR). 


A 
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PART  I - TECHNICAL  APPROACH 


2.0  SREM  OVERVIEW 

The  Software  Requirements  Engineering  Methodology  has  been  developed 
in  parallel  with  development  of  the  Requirements  Enqineering  and  Validation 
System.  As  a consequence  of  this  integrated  development,  there  is  a clean 
and  comprehensible  compatibility  between  the  methodology  and  the  instruments 
it  uses  to  formulate  and  test  a requirements  specification.  While  REVS 
embodies  the  language  and  tools  required  for  orderly  development  of  pro- 
cess requirements  specifications,  SREM  defines  the  techniques  and  proce- 
dures within  which  the  tools  and  sound  engineering  and  management  practices 
are  combined  to  generate  a specification  containing  the  desired  properties. 

SREM  encompasses  four  major  areas  of  engineering  activity  that  begin 
with  receipt  of  the  set  of  information  which  defines  the  system  level 
requirements  on  the  Data  Processing  Subsystem.  This  input  set  is  denoted 
as  the  Data  Processing  System  Performance  Requirements  (DPSPR)  Specification. 

The  DPSPR  includes  the  Data  Processing  System  Interface  Requirements 
Specifications  and  any  external  subsystem  Performance  Requirements 
Specifications  which  influence  the  definition  of  the  Process  Performance 
Requirements.  Using  these  source  documents  as  a stimulus,  the  requirements 
engineer  becomes  involved  in  the  four  major  engineering  activities  defined 
by  SREM  to  develop  the  Process  Performance  Requirements  Specification. 

These  engineering  activities  are: 

• Identification,  definition  and  development  of  the 
functional  requirements, 

• Identification,  definition  and  development  of  the  performance 
requi rements , 

• Development  of  the  Process  Performance  Requirements  Speci- 
fication and 

• Development  of  the  analytic  feasibility  demonstrations. 
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The  inherently  sequential  nature  of  the  steps  of  the  methodology 
appeared  at  first  to  make  incremental  specification  of  software  awkward. 
Experience  on  many  programs,  notably  Systems  Technology  Program*,  has  made 
it  clear  that  any  new  technology  should  assume  that  knowledge  of  require- 
ments will  increase  continuously  throughout  the  development  of  the  software 
specification,  rather  than  be  complete  when  software  requirements  are  first 
initiated.  Thus,  the  tools  and  methodology  of  SREP  were  developed  to 
allow  for  incremental  development  of  the  specification.  Specific  features, 
such  as  VERSION  and  the  qualified  inclusion  of  R_NETs  in  a simulation 
provide  the  capability  either  for  defining  segments  of  the  software  require- 
ments, or  for  augmenting  a full  subsystem  with  additional  functions. 

The  consistency  and  Integrity  enforced  by  the  system  are  fundamental 
to  success  in  incremental  specification.  They  ensure  that: 

t Portions  of  the  system  specified  later  than  some  segments 
will  be  consistent  since  their  connectivity  with  the  early 
segments  was  defined  at  the  highest  levels;  and 

• Any  extension  of  the  system  will  be  compatible  with  prior 
specifications,  since  any  inconsistency  would  preclude 
entering  the  extension  into  the  ASSM. 

During  each  activity  of  SREM  the  features  of  REVS  are  utilized  to 
control,  monitor,  test  and  maintain  the  evolving  collection  of  requirements 
statements.  The  functional  requirements  are  defined  in  RSL  statements  and 
catalogued  by  REVS  in  the  ASSM  by  the  RSL  Translator.  The  accuracy  and 
correctness  of  these  RSL  statements  is  verified  by  the  Statis  Analyzer 
portion  of  the  RADX  segment  of  REVS.  Continuity  and  completeness  of  these 
RSL  statements  is  analyzed  through  the  Simulator  Generation  and  Simulation 
Execution  functions  of  REVS  using  algorithms  for  each  functional  require- 
ment represented  as  executable  PASCAL  procedures  implemented  as  BETA  models. 
Next,  the  performance  requirements  are  defined  in  RSL  statements  and 
catalogued  by  REVS  in  the  ASSM  (by  the  RSL  Translator)  and  attached  to  the 
functional  requirements  each  CONTRAINTS.  The  accuracy  and  correctness  of 
these  RSL  statements  are  again  verified  by  the  Static  Analyzer  portion  of 


*Formerly  the  Site  Defense  Program 
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the  RADX  segment  of  REVS.  Continuity  and  completeness  of  these  RSL  state- 
ments is  analyzed  through  the  Simulator  Generator  and  Simulation  Execution 
functions  of  REVS  using  algorithms  for  each  functional  requirement,  repre- 
sented as  executable  PASCAL  procedures  implemented  as  GAMMA  models.  Vali- 
dation of  the  functional  and  performance  requirements  testability  is  con- 
firmed by  REVS  through  execution  of  TESTs  implemented  as  executable  PASCAL 
procedures.  In  this  way,  the  existence  of  a feasible  design  solution  for 
the  collection  of  functional  and  performance  requirements  statements  is 
confirmed  by  REVS  through  candidate  algorithms  used  as  the  GAMMA  models, 
and  a model  of  the  System  Environment  and  Threat  Simulation  (SETS).  The 
models  are  executed  against  one  another  with  a variety  of  scenarios  to 
demonstrate  the  existence  of  a solution  to  the  requirements  statement  in 
the  ASSM.  Finally,  data  collected  through  RADX  are  formatted  and  published 
as  a Process  Performance  Requirements  Specification. 

The  detailed  description  of  the  SREM  technique  of  specifying  software 
functional  and  Derformance  requirements  is  presented  in  Sections  3 and  4. 

The  methodology  is  described  in  the  context  of  an  example  which  is  defined 
to  the  degree  necessary  to  illustrate  the  method.  The  example  Is  a 
hypothetical  system  called  Track  Loop  System  (TLS).  TLS  is  representative 
of  the  kind  and  complexity  of  real  BMD  systems,  and  yet  is  simple  enough 
to  serve  as  a comprehensible  example.  A complete  DPSPR  (including  the 
interface  specifications)  for  TLS  is  provided  as  Appendix  A.  The  system 
is  summarized  below. 

2.1  THE  TRACK  LOOP  SYSTEM  EXAMPLE 

The  Track  Loop  System  (TLS)  is  a subset  of  a Preliminary  Ballistic 
Missile  Defense  System  that  is  capable  of  nearly  autonomous  execution  in 
response  to  external  stimuli.  It  is  the  simplest  known  BMD  subsystem  with 
properties  of  interest  for  software  definition,  and  it  is  one  which  has 
been  studied  extensively,  both  in  the  academic  literature  and  in  such 
practical  programs  as  Site  Defense.  Therefore,  it  has  been  selected  as 
the  testbed  for  supporting  experimentation  in  development  of  the  methodology 
for  software  requirements.  A pictorial  representation  of  the  TLS  is  pro- 
vided in  Figure  2-1. 


2-3 


RADAR  ORDERS 


n * r-»  a n nrmmir 
tw-iun.'X  r\i_  i u;\.  iO 


2-4 


2.1.1  Preliminary  Ballistic  Missile  Defense  System 

A Preliminary  Ballistic  Missile  Defense  System  (PBMDS)  has  been 
postulated  as  an  environment  in  which  the  TLS  would  execute.  It  is  a 
generalized  representative  of  the  class  of  systems  currently  in  develop- 
ment, and  is  particularized  for  the  TLS  through  representative  but  non- 
real  specifications  where  required.  In  the  Conduct  Engagement  mode,  an 
object  entering  the  search  region  will  be  detected  and  designated,  tracked, 
discriminated,  and  engaged  (as  required)  in  defense  of  the  ground  facilities. 
Those  functions  are  implemented  through  the  Data  Processing  System  (DPS), 
a radar  or  other  sensor,  and  a means  of  neutralizing  hostile  objects.  For 
the  purpose  of  the  TLS,  only  the  radar  need  be  defined  in  detail;  other 
system  elements  are  identified  only  to  the  extent  that  they  impact  DPS 
requirements. 

2.1.2  TLS  Requirements 

The  TLS  is  required  to  perform  five  system  level  functions:  1)  system 
initialization  and  engagement  initiation,  2)  engagement  termination,  3)  tar- 
get tracking,  4)  control  of  system  resources,  and  5)  recording  of  data  during 
the  engagement.  The  system  includes:  the  DPS,  the  radar  and  the  recording 

media, and  directly  interfaces  with  the  external  environment  through  commu- 

2 

nications  and  control  (C  ). 

? 

In  general,  the  functions  of  TLS  are  initiated  by  messages  from  C ; 

however,  track  maintenance  and  certain  control  functions  are  autonomous. 

2 

The  engagement  is  initiated  and  terminated  by  C messages;  during  engagement, 
radar  data  are  reported  to  the  DP  periodically.  When  an  Image  is  handed 
over  to  TLS  through  C , it  is  tracked  without  further  direction,  until  it 
is  dropped  either  by  command  or  by  determination  within  the  DPS.  This 
configuration  thus  demonstrates  both  exogenous  and  endogenous  process 
excitation,  and  in  other  ways  provides  a microcosm  of  a BMD  process. 

2.2  SUMMARY  OF  APPENDICES 

The  Appendices  provide  a summary  of  the  Requirements  Statement 
Language  and  a complete  development  of  the  TLS  requirements  statements. 

A complete  description  of  RSL  Is  provided  In  the  REVS  Users  Manual 
(Volume  II  of  this  report). 
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Appendices  A through  C contain  the  TLS  source  specifications  from 
which  the  TLS  requirements  were  developed.  Appendix  D summarizes  the  RSL 
Terminology  by  providing  a copy  of  the  RSL  nucleus  which  defines  each 
element  of  the  language  and  an  illustration  of  the  symbology.  Appendix  F 
represents  the  TLS  kernel  which  contains  the  flow  and  data  hierarchies 
developed  as  a result  of  the  methodology  defined  in  Section  3.2.  Appendix 
G presents  the  set  of  R-NETs  and  SUBNETS  produced  by  the  Calcomp  capability 
of  the  interactive  graphics  segment  of  REVS.  Appendix  H represents  the 
complete  TLS  Data  Base  maintained  in  the  ASSM  as  extracted  by  the  RADX 
segment  of  REVS. 

The  RSL  requirements  statements  in  the  Appendices  have  been  produced 
by  REVS  from  the  ASSM  in  much  the  same  manner  that  the  information  content 
of  a software  specification  would  be  developed.  Editing  of  this  information 
into  a specification  document  would  be  adapted  to  the  particular  needs  of 
a specific  program.  A sample  PPR  speci fication  was  produced  in  Reference  [2] 
and  the  review  it  elicited  has  underscored  the  need  for  adaptation  of  the 
extracted  information  to  the  specifics  of  an  application.  Therefore, 
neither  REVS  nor  SREM  is  designed  to  produce  a set  specification  format; 
this  final  step  is  left  to  the  discretion  of  the  user  based  on  the  needs 
of  each  particular  program. 
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3.0  FUNCTIONAL  REQUIREMENTS 


Software  requirements  can  be  viewed  as  defining  either  what  must  be 
accomplished  or  how  well  an  activity  must  be  done.  The  former  is  termed 
a "functional  requirement",  since  it  specifies  data  processing  functions; 
the  latter  is  termed  a "performance  requirement"  since  it  constrains  the 
quality  of  performance  of  the  function  in  the  system.  In  another  sense,  a 
functional  requirement  can  be  thought  of  as  defining  the  required  output  in 
terms  of  the  available  inputs.  In  a simple  case,  a program  might  be  named 
SUMMER  and  have  a functional  requirement  of  generating  the  sum  of  a sequence 
of  input  numbers  (X^.  Defining  the  output  after  the  ith  input  to  be  , 
the  performance  requirement  might  be  that  (Y.+i  - Y^)  be  within  e of  X^. 

Note  that  while  the  functional  requirement  specifies  what  must  be 
done,  and  the  performance  requirement  constrains  how  well  it  must  be 
accomplished,  the  means  of  accomplishment  is  left  to  the  software  process 
designer.  Since  the  means  of  implementation  is  not  specified,  the  require- 
ments are  then  said  to  be  design-free. 

Forms  and  techniques  for  representing  functional  requirements  have 
evolved  in  recent  years  and  have  culminated  in  the  concept  of  Requirements 
Networks  (R_NETs).  Originally,  verbal  descriptions  of  functions  were 
attempted,  but  the  verbiage  was  found  to  be  cumbersome  and  ambiguous.  Later, 
through  Engagement  Logic  and  Functional  Flow  Block  Diagrams  (FFBD's), 
diagrams  replaced  many  words  in  the  requirements  specification,  unfortunately 
much  of  the  ambiguity  remained.  Notably,  it  was  difficult  in  practice  to 
trace  required  processing  paths;  data  definitions  were  incomplete;  and 
these  mechanisms  did  not  lend  themselves  to  consistency  or  completeness 
analysis. 

To  resolve  the  problem  of  recognizing  processing  paths,  a thread 
description  was  attempted;  however,  the  number  of  threads  in  a real  system 
proved  so  large  that  the  (essentially  one-dimensional)  representation  was 
almost  as  hard  to  use  as  conventional  English  text.  Conversion  to  the 
concept  of  thread  trees  somewhat  reduced  the  magnitude  of  the  thread 
problem,  but  did  not  of  itself  resolve  the  other  difficulties  of  undesired 
specificity  (in  AND  branches),  ambiguity  (especially  in  data),  and 
awkwardness  for  analysis. 
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SREM  embodies  the  thread  tree  (R_NET)  concept  for  specification  of 
processing  paths  and  augments  the  overall  capability  in  terms  of  precision 
and  explicitness.  Specifically,  the  desirable  properties  preserved  in  the 
SREM  concept  of  R_NETs  were: 

• Graphic  representation  of  functional  requirements 

• Path  orientation  for  specification  of  threads 

t Design  (implementation)  independence. 

In  addition,  the  use  of  R_NETs  permitted  inclusion  of  the  following  addi- 
tional desired  properties: 

• Unambiguous  statement 

• Analyzable  models 

• Explicit  data  specification. 

In  effect,  these  six  properties  became  the  top-level  specification  for  the 
tools  (REVS/RSL)  and  methodology  (SREM)  for  functional  requirements  speci- 
fications. 

It  is  significant  that  the  properties  carried  over  from  previous 
approaches  are  those  relating  to  subjective  measures  of  legibility, 
utility  and  design  freedom.  The  added  properties  are  objectively  assessible 
most  readily  by  demonstration.  Thus,  a part  of  the  SREM  has  been  the 
demonstration  of  completeness,  freedom  from  ambiguity,  and  other  attributes 
through  static  analyzers  of  the  explicit  (machine-readable)  Requirements 
Statement  Language.  By  expressing  functional  requirements  in  machine- 
readable  form,  and  by  using  the  tools  developed  on  a variety  of  programs 
in  both  industry  and  academia,  it  is  possible  to  generate  an  ultimate  test 
of  a functional  specification,  i.e.,  a functional  simulation.  A simulator 
built  without  human  intervention  from  specification  statements  is  a total 
demonstration  of  the  consistency,  precision,  and  completeness  of  that 
specification.  With  a suitable  driver,  such  a simulation  provides  a 
mechanism  for  defining  frequency  of  transactions,  and  examination  of  gross 
aspects  of  system  tradeoffs. 

Fundamentally,  there  are  three  different  ways  of  conceiving  soft- 
ware requirements.  The  classical  approach  is  functional,  i.e.,  what 
operations  are  to  be  performed  by  system  logic  embodied  in  the  software. 
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Secondly,  a thread  approach  is  more  nearly  mechanical,  i.e.,  what  are  the 
interfaces  and  the  properties  of  the  messages  communicated  through  them. 

The  third  concept  may  be  termed  philosophical;  i.e.,  what  are  the  realities 
of  the  world  the  DPS  perceives  and  what  information  about  those  realities 
must  be  manipulated.  Each  approach  can  lead  to  mechanisms  by  which  require- 
ments may  be  generated;  SREM  uses  all  three  concepts  concurrently. 

The  functional  approach  is  embodied  in  the  concept  of  a Requirements 
Network  (R_NET),  which  defines  the  processing  flow  required  of  the  software. 
The  mechanical  concepts  are  reflected  in  the  heavy  dependence  of  SREM  on 
definitions  of  messages  through  interfaces  in  establishing  the  top  level  of 
data  hierarchies.  The  philosophical  concept  is  preserved  in  the  implementa- 
tion-independent hierarchies  defined  within  the  concept  of  entities. 

Activities  defined  by  SREM  that  lead  to  specification  and  validation 
of  the  functional  requirements  have  been  segmented  into  five  phases; 


Phase  1 - Definition  of  Subsystem  Elements 

Phase  2 - Kernel  Evaluation 

Phase  3 - Completion  of  Functional  Definition 

Phase  4 - Completion  of  Management  & Control  Information 

Phase  5 - Dynamic  Functional  Validation 

The  activities  and  steps  within  each  of  these  phases  are  described  in  the 
following  sections  in  the  context  of  the  Track  Loop  example. 
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3.1  PHASE  1 - DEFINITION  OF  SUBSYSTEM  ELEMENTS 


There  are  two  different  "structural"  elements  to  be  defined  in  the 
first  stage  of  functional  specification.  One  is  the  flow  connectivity 
previously  represented  with  Engagement  Logic  or  FFBD's.  The  other,  con- 
tained in  the  current  methodology  (SREM),  defines  the  required  data 
hierarchies.  Previously,  a specific  methodology  was  not  available  for 
definition  of  flow  connectivity.  By  adding  the  data  hierarchy  to  the 
structures,  a step-by-step  approach  to  top-level  requirements  development 
has  been  identified  in  which  only  those  areas  requiring  engineering 
creativity  are  left  unconstrained  (however,  these  areas  are  clearly  identi- 
fied). 

The  first-time  SREM  user  may  find  it  necessary  to  reorient  his  thought 
processes  to  effectively  use  the  methodology,  the  language  and  the  software 
tools.  In  time,  however,  the  phases  and  steps  will  form  a natural 
progression  for  the  job  to  be  accomplished.  The  requirements  engineer  and 
management  should  always  keep  in  mind  that  their  task  is  to  develop 
requirements  for  software  and  not  to  design  the  software  itself.  The 
pertinent  question  is  to  constantly  ask,  "Is  this  a precise  statement  of 
what  the  DPS  is  required  to  do  in  the  most  qeneral  wav  such  that  the  process 
designer  has  a maximum  range  of  choices  in  deriving  a solution?" 

A typical  specification  process  usually  starts  with  a formulation  of 
the  processing  steps  involved  and  later  considers  the  data  needed  to  support 
that  processing.  SREM  partially  reverses  this  order  of  consideration;  the 
order  of  concern  is  1)  “What  data  are  presented  to  the  DPS  for  processing?", 
and  2)  "What  data  are  expected  from  the  DPS  as  output?"  From  the  answers 
to  these  questions,  an  initial  concept  of  the  required  processing  steps 
can  be  derived. 

As  a general  guideline,  it  ir  suggested  that  the  work  at  each  step  be 
completed  before  proceeding  to  the  next  step.  In  large  projects,  involving 
many  people,  the  needs  of  communication  and  coordination  make  this  mandatory. 
In  smaller  projects,  especially  those  involving  one  or  two  people,  tnere  is 
often  a rush  to  do  all  the  steps  for  one  small  area  of  the  system  before 
considering  the  next  area  of  concern.  This  may  be  possible  for  a DPS 
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problem  where  the  processing  functions  are  independent,  but,  at  best,  many 
valuable  insights  into  the  required  operation  of  the  DPS  as  a whole  may  be 
lost.  At  worst,  a significant  amount  of  rework  may  be  involved. 

3.1.1  Initial  Inputs 

The  initial  inputs  required  for  application  of  SREM  are,  typically,  a 
system  specification  and  its  companion  interface  specifications.  The  objec- 
tive is  to  generate  a complete  specification  for  the  data  processing  sub- 
system (DPS)  from  these  basic  inputs.  Usually,  at  this  early  stage  of 
system  development  the  input  specifications  are  incomplete,  contain  many 
ambiguities,  and  leave  several  issues  for  future  resolution.  SREM  does  not 
require  that  all  omissions  be  resolved  before  proceeding.  Instead,  a user 
can  proceed  from  that  which  is  clearly  defined,  and  use  the  facilities  of 
the  RSL  management  segment  to  spotlight  issues  needing  resolution.  Assump- 
tions and  decisions  may  be  necessary,  often  based  on  inadequate  data.  These 
should  not  be  avoided  but  rather  entered  in  the  ASSM  using  the  RSL  element 
DECISION  and  its  attributes.  The  important  thing  is  to  make  these  entries 
as  they  arise.  This  not  only  leaves  a traceable  record  of  current  status 
for  others,  but  leaves  a valuable  record  of  the  evolution  of  critical 
thoughts  about  the  subsystem  for  future  reference. 

The  methodology  documented  here  refers  to  one  of  many  practical 
starting  points  for  developing  software  requirements ; in  particular,  it 
refers  to  one  which  is  consistent  with  top-down  system  evolution.  It 
assumes  that  a system  specification  and  the  key  interface  specifications 
have  been  developed  to  a significant  level -of-detai 1 to  enable  requirements 
definition  and  that  the  allocation  of  functions  to  the  subsystems  (notably, 
to  the  DPS)  has  been  completed.  Basically,  the  methodology  is  essentially 
unchanged  if  the  tools  are  applied  either  earlier  or  later  in  the  develop- 
ment process,  but  the  amount  of  effort  needed  in  each  phase,  particu- 
larly the  extent  of  creativity  which  must  be  applied,  varies  greatly. 

Consequently,  the  present  methodology  is  sufficient  for  the  defined 
starting  point  and  is  readily  adaptable  if  the  tools  are  applied  either 
during  system  definition  cr  after  code  design  (as  a V&V  tool). 
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Figure  3-1 


RSL  Subsystem  Entries 


3.1.2  Interface  Definition 


The  first  RSL  entries  in  the  ASSM  are  concerned  with  identification 
of  the  DPS  interfaces  which  CONNECT  with  other  subsystems.  Usually,  these 
are  the  elements  which  are  most  clearly  defined  in  the  originating  speci- 
fications. Also,  it  has  been  found  that  the  interfaces,  and  the  messages 
passing  through  them,  are  the  key  focal  points  for  progressive  development 
of  the  requirements  structure. 

Consider  the  TLS  specification  (DPSPR)  and  interface  specifications 
(IFSs)  contained  in  Appendices  A,  B,  and  C.  These  documents  refer  to  two 

O 

subsystems  which  interface  with  the  DPS,  namely  the  Radar  and  C (Command 

p 

and  Communications).  C will  be  referred  to  as  a subsystem  for  convenience, 
even  though  it  is  a separate  system,  external  to  the  TLS.  A closer  exami- 
nation of  the  DPSPR  reveals  that  the  DPS  is  to  output  data  to  permanent 
files.  Although  not  explicitly  required  by  the  specification  it  will 
later  become  apparent  that  it  is  conceptually  useful  to  define  permanent 
storage  as  a third  subsystem  separate  from  the  DPS,  even  though  it  is 
embedded  in  the  DPS.  For  REVS  use,  these  three  subsystems  have  been 
designated  as  SSRADAR,  SSC2,  and  SSPERMFL,  respectively. 

In  the  specifications,  three  separate  interfaces  between  the  DPS  and 
the  Radar  are  mentioned.  Through  one  input  interface  the  radar  sends 
returns  to  the  DPS;  through  another  it  sends  clock  inputs  to  the  DPS.  The 
DPS  issues  commands  to  the  radar  through  an  output  interface.  These 
interfaces  are  designated  as  RADAP_IN,  RADAR_CLOCK_IN , and  RADAR_0UT, 
respectively.  The  names  are  arbitrary,  but  should  be  meaningfully  related 
to  specification  terminology.  Note  that  an  interface  is  designated  as 
"input"  or  "output"  from  the  viewpoint  of  the  DPS. 

Similarly,  the  specifications  identify  one  input  interface  between 

C2  and  DPS.  (Denoted  as  input  interface  CC I N ) . Data  recorded  by  the  DPS 

in  permanent  storage  apparently  are  never  accessed  from  that  source  during 
DPS  operation.  Therefore,  the  DPS  is  liiked  to  the  conceptual  subsystem 
SSPERMFL  via  an  output  interface,  DATA_RECORD. 

At  this  point,  the  subsystem  and  interface  definitions,  and  their 
relationships,  can  be  coded  in  RSL  for  entry  into  the  ASSM.  Figure  3-1 
illustrates  one  way  of  expressing  these  data  in  RSL.  Note  that  the 
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management  segment  attribute,  DESCRIPTION,  has  been  used  to  explain  the 
nature  of  SSPERMFL.  This  entry  is  for  example  purposes  here,  and  will  not 
be  perpetuated  in  the  TSL  example.  However,  notations  such  as  this  have 
value  in  a real  system  development  project  and  should  be  encouraged. 

Also  note  that  the  DPS  itself  is  not  entered  into  the  ASSM  as  a 
SUBSYSTEM,  since  it  is  inherently  the  object  of  all  software  requirements. 

3.1.3  Message  Definition 

Having  defined  the  subsystems,  the  interfaces,  and  their  connections, 
the  next  step  is  to  examine  the  discrete  blocks  of  data,  or  MESSAGES  which 
are  PASSED  BY  the  interfaces.  A MESSAGE  is  MADE  BY  its  contents,  whether 
they  be  DATA  or  FILES. 

Using  SREM,  the  concepts  of  "message  name”  or  "message  category" 
differ  from  that  of  "message  type".  In  RSL,  the  identifier  associated  with 
MESSAGE  refers  to  the  message  name  or  category.  MESSAGES  are  distinguished 
by  differences  in  their  data  contents.  Thus,  two  blocks  of  data  with 
different  data  contents,  which  pass  through  an  interface,  must  be  defined 
as  different  MESSAGES,  hence  must  have  different  message  names.  The 
message  name  is  not  contained  in  the  data,  it  is  an  external  label. 

On  the  other  hand,  two  packets  of  data  may  have  identical  data  con- 
tent with  different  values,  and  may  require  different  processing  to  be 
done  on  the  data  within  the  DPS.  In  this  case  there  would  be  two  instances 
of  the  same  MESSAGE,  but  with  different  "message  type".  Further,  it  is 
typical  for  one  of  the  data  elements  in  the  message  to  be  a message  type 
identifier,  with  a unique  value  for  each  type.  Otherwise,  the  DPS  could 
not  distinguish  between  types  of  messages  and  perform  different  processing 
operations  on  each  type.  Messages  with  different  names  must  also  ha:e  a 
unique  identifier  in  order  for  the  DPS  to  distinguish  between  messages. 

It  is  most  economical  to  require  that  all  messages,  whether  of  different 
name  or  type, contain  a type  identifier  as  a data  element  with  a unique 
value,  different  from  the  message  name.  This  avoids  both  mental  confusion 
and  possible  misinterpretation  by  the  RSL  translator. 


TYPES:  START 
STOP 


TYPES:  FEET 
INCHES 


Figure  3-2  An  Elementary  Interface  Hierarchy 
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To  illustrate  these  concepts,  consider  a DPS  with  one  input  interface 
called  IN.  Across  this  interface  pass  four  distinct  types  of  messages. 

The  first  two  types  consist  of  a single  data  element  with  different  values: 
START,  STOP.  These  command  the  DnS  to  start  and  stop  processing,  respec- 
tively. The  second  two  types  consist  of  a data  element  with  two  values: 

FEET,  INCHES.  This  element  defines  which  units  the  real  number  is  in. 
Further,  the  DPS  is  to  convert  the  input  data  to  meters  for  further 
processing. 

These  messages  can  be  distinguished  by  defining  a data  element 
MESSAGE_TYPE  with  four  enumerated  values:  START,  STOP,  FEET,  INCHES.  For 
the  types  FEET  and  INCHES,  an  associated  data  element,  LENGTH,  can  be 
defined.  Over  the  four  message  types  two  categories  can  be  identified 
according  to  data  content  and  function.  The  first  category  consists  of 
messages  with  only  one  data  element,  MESSAGE_TYPE,  which  provides  commands 
to  the  DPS.  The  second  category  consists  of  messages  with  two  data  elements, 
MESSAGE_TYPE  and  LENGTH,  which  provide  dimensional  input  data  to  the  DPS. 

The  first  category  is  named  a COMMAND  message;  the  second  category  is  a 
DIMENSION  message.  Hence,  a COMMAND  message  has  two  types:  START  and 
STOP.  A DIMENSION  message  also  has  two  types:  FEET  and  INCHES.  This 
latter  message  could  not  be  called  LENGTH  because  that  name  is  assigned  to 
one  of  the  data  elements  within  the  message. 

The  message  names,  types,  and  data  contents  associated  with  the  vari- 
ous interfaces  must  be  extracted  from  the  system  and  interface  specifica- 
tions, often  from  widely  scattered  locations.  Sometimes  the  specifications 
only  define  message  types,  and  the  requirements  engineer  must  group  these 
into  categories  which  will  be  named  MESSAGES  in  RSL.  For  these  reasons, 
some  pencil -and-paper  preliminary  work  is  usually  needed  to  organize  the 
data  before  translating  them  into  RSL  inputs.  One  diagrammatic  represen- 
tation of  the  messages  passing  an  interface,  that  has  proved  useful,  is 
shown  in  Figure  3-2  for  the  simple  example  discussed  above. 

The  diagram  is  simply  a tree  originating  at  the  interface.  Each 
branch  of  the  tree  terminates  in  a box  corresponding  to  a MESSAGE  name. 

Data  elements  common  to  all  messages  are  placed  on  the  tree  before  the 
first  branch  point.  Data  elements  unique  to  a specific  message  are  placed 
on  the  branch  unique  to  that  message.  Elements  common  to  two  or  more 
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messages,  but  excluded  from  others,  are  placed  on  an  intermediate  branch 
leading  only  to  the  appropriate  messages.  (The  TLS  example  discussed  below 
will  illustrate  this  latter  condition.)  The  data  element  names  may  refer 
to  data  items,  or  files.  It  is  useful  to  note  files  as  such  on  the 
diagram.  A file  is  a collection  of  instances  of  data  items,  each  instance 
having  the  same  structure.  If  desired,  the  types  of  each  message  can  be 
noted  below  the  message  name.  While  the  diagrammatic  format  shown  has 
proven  useful,  it  is  in  no  way  mandatory.  Whatever  notation  or  format  aids 
a specific  problem  should  be  used.  The  important  point  is  to  organize  the 
material  on  paper  before  writing  the  RSL  inputs. 

A useful  rule-of-thumb  for  using  SREM  is:  don't  define  details  until 
they  are  needed  for  the  purposes  nf  the  moment.  At  this  stage  of  an 
analysis,  interest  is  focused  solely  in  the  elements  which  are  common,  and 
unique,  to  the  various  message  types.  No  further  detail  is  needed.  For 
instance,  if  it  is  known  that  an  identifiable  group  of  data  is  unique  to 
a given  message,  it  is  only  necessary  to  name  the  group  as  a data  item  on 
the  tree.  In  practice  this  is  often  easy,  because  the  exact  composition 
of  the  group  may  be  ambiguous  long  after  the  group  itself  is  identified. 

In  any  case,  the  composition  of  a group  is  easily  defined  by  the  RSL 
relation  INCLUDES  when  that  level  of  detail  is  needed. 

Now,  consider  the  messages  in  the  TLS  example,  starting  with  those 

coming  from  the  "subsystem".  Paragraph  3.2  of  the  TLS  C^/DPS  IFS  states 

2 

that  four  types  of  messages  are  transmitted  from  the  C to  the  DPS: 

• Initiate  Engagement  Mode 

• Terminate  Engagement  Mode 

• Handover  Image 

• D^op  Image  Track 

Implicitly  common  to  all  these  message  types  is  some  sort  of  message 
type  identifier.  Since  these  are  all  common  messages  they  were  assigned 

a single  identifier  ( COMMAND I D ) . Paragraphs  3.2.1  and  3.2.2  of  the  IFS 

imply  that  there  are  no  other  data  elements  in  the  first  two  message  types. 
Both  of  these  types  have  a common  function,  namely  to  command  a change  in 
the  operating  mode  of  the  DPS.  Thus,  they  form  a single  MESSAGE  category 
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(named  MODE_CHANGE) . Hence,  as  shown  in  the  diagram  of  Figure  3-3,  there 
is  a message  MODE_CHANGE,  of  two  types,  with  a single  data  element, 
COMMANDED,  which  distinguishes  the  two  types. 

The  remaining  two  message  types  contain  other  data  elements,  in 
addition  to  COMMANDED,  as  stated  in  paragraphs  3.2.3  and  3.2.4.  Common  to 
both  is  an  element  called  variously  "image  designation",  or  "image  desig- 
nator", but  which  is  obviously  a single  element  called  HO I D (shortened 

from  HANDOVER_ID) . This  additional  element  completes  the  definition  of  the 
"Drop  Image  Track"  type  message.  Since  the  data  content  of  this  message 
is  unique,  it  forms  a message  category  by  itself.  The  identifier  TERMINATION 
was  chosen  in  order  to  reserve  DROP_TRACK  for  use  as  an  enumerated  value  of 
COMMANDJD. 

The  remaining  message  type  is  also  in  a category  by  itself,  in  this 
example  named  a HANDOVER  message.  In  addition  to  COMMANDED  and  H0_ID, 
paragraph  3.2.3  of  the  IFS  states  that  this  message  contains  a data  element 
"image  estimated  state".  However,  paragraph  1.1.2.1a  of  the  DPSPR.  refers 
to  an  "estimate  of  state",  while  paragraph  1.2.2.1g  states  that  "each 
handoff  shall  consist  of  a unique  designator,  the  state  vector,  and  its 
covariance  matrix."  At  this  point  the  data  element  could  be  defined  as 
INITIAL_STATE_ESTIMATE.  But,  it  seems  worthwhile  to  state  the  main  com- 
ponents, since  they  are  not  stated  in  the  IFS  paragraph  where  one  would 
expect  to  find  them.  Thus,  two  data  elements  are  defined,  INITIAL_STATE 
and  INITIAL_COVARIANCE,  to  represent  the  vector  and  matrix,  respectively. 

The  prefix  "initial"  is  used  to  avoid  confusion  with  state  data  generated 
by  the  DPS  in  the  course  of  subsequent  processing.  Note  that  there  is  no 
need,  at  this  point,  to  define  the  vector  components  and  matrix  elements 
individually.  The  definition  of  messages  related  to  the  CC_IN  interface, 
as  shown  in  Figure  3-3  have  now  been  completed.  These  messages  can  be 
defined  In  RSL  as  shown  in  Figure  3-4.  Although  not  shown  here,  it  is 
useful  to  use  the  capabilities  of  the  management  segment  of  RSL  to  note 
the  source  of  the  state  data  definitions  in  the  handover  message,  and  to 
point  out  that  the  IFS  is  incomplete  or  at  variance  with  the  DPSPR. 
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Figure  3-4  RSL  Message  Entries 
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3.1.4  The  Interface  Data  Hierarch 


At  this  point  the  elements  of  one  of  the  two  major  data  hierarchy 
types  associated  with  SREM  have  been  partially  defined.  This  is  the 
"interface  data  hierarchy"  depicted  in  Figure  3-5. 

A SUBSYSTEM  is  CONNECTED  TO  either  an  INPUTJNTERFACE  or  an  0UTPUT_ 
INTERFACE  which  PASSES  blocks  of  data  called  MESSAGES.  A MESSAGE  is  MADE 
BY  individual  items  of  DATA,  and/or  by  a group  of  DATA  which  INCLUDES 
individual  DATA  items,  and/or  by  FILEs.  In  turn,  a FILE  CONTAINS  indivi- 
dual DATA  items.  The  RSL  concept  of  FILE  is  more  general  than  the  usual 
software  connotation.  It  is  a collection  of  instances  of  data,  each 
instance  having  the  same  conten*  of  data  items,  without  regard  to  the 
details  of  storage,  and  without  ordering  unless  specified. 

In  general,  a data  item  must  have  a different  DATA  name  in  each  hier- 
archy in  which  it  appears,  even  though  the  different  names  refer  to  the 
same  information.  The  exception  is  that  DATA  or  FILEs  may  exist  in  more 
than  one  MESSAGE  due  to  the  fact  that  only  one  MESSAGE  can  be  active  in 
the  REVS  system  at  any  particular  time.  Therefore,  the  assembly  of  DATA 
and  FILEs  into  a MESSAGE  is  unambiguous  regardless  of  the  number  of  MESSAGES 
that  may  be  MADE  BY  that  element.  For  example,  a MESSAGE  PASSED  THROUGH  an 
INPUT_INTERFACE  only  exists  at  the  instant  of  passage  (i.e.,  the  enablement 
of  the  interface  network).  An  ALPHA  accesses  not  the  MESSAGE  but  the  DATA 
it  contains;  there  can  be  no  ambiguity  among  those  DATA  items  regardless 
of  the  number  of  MESSAGES  which  might  contain  them,  since  there  can  be  no 
more  than  one  MESSAGE  entering  the  system  for  a given  enablement. 

SREM  is  heavily  oriented  toward  an  orderly  analysis  of  the  interface 
data  hierarchies,  in  a "top-down"  direction,  as  the  first  step  in  defining 
DPS  requirements.  This  is  a natural  direction,  as  the  interfaces  and  the 
messages  crossing  them  are  usually  the  most  clearly  defined  elements  of  the 
originating  specifications.  As  the  data  definitions  are  developed  in 
progressively  greater  detail,  the  definition  of  specific  processing  steps, 
or  ALPHAs,  begins  to  emerge,  as  well  as  the  processing  flow  STRUCTURE  which 
1 Inks  the  ALPHAs. 


For  INPUT_INTERFACES,  the  "top  down"  consideration  of  the  data  hier- 
archy follows  the  flow  of  processing.  For  OUTPUT_INTERFACEs , the  "top  down" 
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Figure  3-5  Interface  Data  Hierarchy 
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direction  is  opposite  to  the  processing  flow.  However,  backward  tracing 
from  the  output  interface  is  a valuable  tool  in  constructing  the  steps 
necessary  to  form  an  output  MESSAGE. 

Initially,  the  internal  processing  required  of  the  DPS  may  be  ill- 
defined  and  ambiguous.  The  requirements  engineer  will  need  to  draw  heavily 
on  experience  to  synthesize  the  connections  between  input  and  output.  As 
a broad  guideline,  the  primary  concern  is,  "What  must  be  done  to  the  data 
that  is  input  in  order  to  provide  the  required  output?" 

3.1.5  Problems  of  Definition 

In  general,  specification  documents  written  in  English  text  contain 
statements  which  yield  different  meanings  depending  on  a particular  inter- 
pretation. Confusion  and  ambiguity  usually  result  when  the  requirements 

engineer  encounters  specification  statements  similar  to  subparagraphs  3.2.5 
2 

and  3.2.6  of  the  C /DPS  IFS.  These  two  innocent  subparagraph  titles  lead 
to  a number  of  confusing  questions,  which  are  typical  of  preliminary 
specifications. 

The  titles  of  subparagraphs  3.2.1  through  3. 2. A correspond  to  clearly 

2 

defined  C to  DPS  message  types,  and  the  content  of  the  text  addresses  those 
types.  The  contents  of  3.2.5,  titled  "Message  Acknowledgement",  and  3.2.6, 
titled  "Error  Handling",  are  TBS  (To  Be  Specified).  Do  these  titles  indi- 
cate additional  input  message  types,  in  conflict  with  the  clear  definition 

in  paragraph  3.2?  If  so,  what  message  is  being  acknowledged  by  "Message 

2 

Acknowledgement"?  No  messages  from  DPS  to  C have  been  defined,  and  no 

2 

requirement  for  a DPS  output  interface  to  the  C system  is  indicated.  In 

fact.  Figure  A-l  of  the  DPSPR  (Appendix  A)  clearly  indicates  that  message 

2 

traffic  is  one-way,  from  C to  DPS. 

On  the  other  hand,  a requirement  for  the  DPS  to  acknowledge  receipt 

o 

of  any  of  the  four  defined  C to  DPS  message  types  by  transmitting  a reply 
to  C2  may  be  intended.  If  so,  both  the  DPSPR  and  IFS  must  be  modified  to 
reflect  this,  without  ambiguity.  Similarly,  "Error  Handling"  might  refer 
to  either  a messaqe  type,  or  to  processing  in  response  to  erroneous  messages. 
Resolution  of  these  questions  is  important  because  major  differences  in  DPS 
definition  result  from  the  alternatives. 
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Work  can  either  be  halted  until  the  problems  are  resolved,  or  can 
proceed  tentatively  with  the  assumptions  which  make  the  most  sense.  If 
the  work  continues,  the  problem  should  be  noted  in  the  ASSM  to  identify 
what  elements  are  affected  by  the  assumptions.  Figure  3-6  shows  one  way 
of  doing  this,  for  the  message  acknowledgement  problem,  using  features  of 
the  RSL  management  segment.  These  entries  announce  the  problem  and 
indicate  changes  needed  later  if  the  assumptions  are  wrong. 
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Figure  3-6  RSL  Decision  Entry 

A possible  objection  is  that  makinq  these  entries  and  recording 
these  questions  is  tedious  and  takes  up  time.  True.  However,  more  time 
will  eventually  be  taken  up  by  other  people  asking  the  same  questions  (over 
and  over  again).  Worse  yet,  others  may  make  different  assumptions  or  fail 
to  detect  the  ambiguities,  resulting  in  more  time  spent  later  in  rework. 
With  the  information  recorded  in  the  ASSM,  the  answers  are  available  to 
everyone  - even  to  those  who  haven't  yet  thought  of  the  questions. 

It  is  not  within  the  scope  of  this  manual  to  explore  all  the  aspects 
of  traceability  and  uses  of  the  RSL  management  segment.  For  further 
development  of  the  TLS  example,  assume  that  the  problems  have  been  resolved 
as  follows: 

• A message  called  ACKNOWLEDGEMENT  consisting  of  one  data 
element,  COMMAND  ID,  is  required. 
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• This  message  is  passed  from  DPS  to  C via  a new  output 
interface,  CC_0UT. 

• "Error  Handling"  refers  to  error  processing  required  of  the 
DPS  when  a message  from  C?  is  not  identified  as  one  of  the 
four  specified  types. 

3.1.6  R_NET  Definition 

A Requirements  Net,  or  R_NET  is  used  to  describe  the  required  flow  of 
processing  in  response  to  a single  stimulus  which  ENABLES  the  net.  This 
stimulus  may  be  either  the  passage  of  a MESSAGE  through  an  INPUT_INTERFACE , 
or  an  EVENT  defined  by  its  arrival  at  a node  on  the  subject  R_NET  or  on 
some  other  R_NET  associated  with  the  DPS. 

Each  INPUT I NTERFACE  must  enable  an  R_NET.  Otherwise,  DATA  in  a 

MESSAGE  passing  the  interface  could  not  be  processed  by  the  DPS.  Hence, 
there  must  be  at  least  one  R_NET  for  each  INPUT_INTERFACE , since  only  the 
processing  on  an  R_NET  can  distinguish  between  the  arriving  messages.  Thus, 
the  first  logical  step  in  defining  the  RJJETs  of  the  DPS  is  to  define 

one  for  each  INPUT I NTERFACE.  In  the  TLS  example,  three  such  interfaces 

have  been  previously  defined,  so  it  is  necessary  to  develop  three  corre- 
sponding R_NETs. 

R_NETs  may  be  entered  into  the  ASSM  manually  from  the  Anagraph  termi- 
nal, or  via  a card  deck  of  RSL  statements.  In  most  cases,  the  net  should 
be  diagrammed  on  paper  first  to  develop  the  concept  fully  and  minimize 
revisions . 

As  a first  example,  consider  the  R_NET  ENABLED  by  INPUT_INTERFACE 

CC I N . The  Input-Interface  is  the  initial  node  on  the  net.  It  is 

reasonable  then,  but  not  mandatory,  to  provide  an  ALPHA  for  common  pro- 
cessing of  all  MESSAGES  through  that  interface,  for  such  purposes  as 
validating  data  coimon  to  all  MESSAGES.  Thus,  a typical  starting  structure 
is : 
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It  was  noted  during  MESSAGE  definition  that  each  was  distinguished 
by  the  differences  in  their  data  contents.  Since  the  input  to  an  ALPHA  is 
fixed,  there  must  be  a unique  ALPHA  for  each  MESSAGE.  There  also  may  be 
several  message  types  for  each  MESSAGE,  and  it  is  reasonable  to  expect 
different  processing,  hence  different  ALPHAS,  for  each  type.  While  not 
always  true,  this  is  usually  a profitable  assumption  at  this  stage  of  R_NET 
development.  Further,  an  additional  ALPHA  is  usually  needed  for  error 
processing  of  messages  not  recognized  as  one  of  the  valid  types.  Therefore, 
it  is  possible  to  draw  the  following  skeleton  associated  with  an  input 
interface  with  the  information  gained  from  our  preceding  analyses  of  the 
specifications.  (Refer  to  Appendix  D,  Figure  D-l  for  symbols  and  allowable 
structures.) 


i 
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The  OR  node  with  multiple  branches,  as  shown,  is  described  in  RSL 
with  the  aid  of  the  CONSIDER  phase.  The  object  of  consideration  is  a data 
element  with  an  enumerated  set  of  values,  in  this  case  the  data  element 
COMMANDED.  If  the  value  of  COMMANDED  in  a particular  message  does  not 
match  one  of  the  four  valid  MESSAGE  types,  then  the  C^_MESSAGE_ERROR  branch 
is  invoked. 

The  ALPHAS  defined  above  reflect  all  processing  required  for  a given 
message  type.  The  names  chosen  reflect  a gross  conception  of  the  nature 
of  the  processing.  They  are  subject  to  change.  As  analysis  proceeds  the 
definition  of  the  R_NET  will  be  refined.  The  first  tentative  ALPHAS  may 
expand,  and  the  branching  structure  will  be  modified  for  all  but  the  sim- 
plest systems.  Hence,  there  should  be  no  rush  to  enter  an  R_NET  into  the 
ASSM  at  the  first  opportunity.  This  activity  is  best  performed  when  the 
definition  of  the  net  has  stabilized  and  possible  relations  with  other 
R_NETs  are  identified. 

Where  the  previous  effort  was  purely  mechanical,  it  is  now  necessary 
to  apply  some  creativity  to  complete  the  interface  network.  There  are  two 
fundamental  approaches  to  that  completion  from  the  available  documentation, 
i.e.,  thread  tracing  and  sentential  analysis.  Both  should  be  used  so  that 
completeness  of  statement  is  assured. 

The  first  operation  is  thread  tracing.  By  reading  the  source  speci- 
fications, the  processing  steps  required  may  be  traced  from  an  input  port 
to  their  logical  termination.  When  all  paths  have  been  traced,  not  only 
for  the  input  networks  but  also  for  those  developed  in  the  following  para- 
graphs, the  set  of  processing  steps  (ALPHAs)  required  should  be  complete. 
Sentential  analysis  provides  a cross-check  by  separating  each  specification 
sentence  into  its  nouns  (which  correspond  to  system  data)  and  its  verbs 
(which  correspond  to  ALPHAs).  The  two  sets  of  ALPHAS  should  be  identical; 
if  not,  they  are  made  to  be  through  refinement  of  the  diagrams. 

The  result  of  specification  analysis  is  completion  of  the  paths  from 

each  INPUT_INTERFACE.  For  example,  there  is  a requirement  in  the  TLS  that 

2 

each  MESSAGE  received  from  C be  acknowledged.  Therefore  the  AND  node  is 
added,  an  ALPHA  is  provided  to  FORM  the  MESSAGE:  ACKNOWLEDGEMENT,  and  the 
appropriate  OUTPUT_INTERFACE : CC_0UT  is  indicated.  Continuing  this 
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process  developed  the  following  diagram.  It  is  a complete  R_NET  for 
CC_RESPONSE  requirements  for  TLS  except  that  it  does  not  yet  reflect  inter- 
network connectivity.  Note  that  each  branch  ends  at  either  an  OUTPUT 

INTERFACE , or  at  a TERMINATE  symbol. 


In  tracing  input  networks,  many  of  the  MESSAGES  to  be  output  by  the 
software  will  have  been  isolated.  However,  not  all  messages  for  any  OUTPUT 
INTERFACE,  nor  indeed  any  MESSAGE  for  some  of  them,  may  be  defined.  Thus, 
there  is  an  inverse  operation  for  output  networks  which  traces  back  from 
an  OUTPUT_INTERFACE  through  individual  ALPHAS  for  each  possible  output 
MESSAGE  to  the  earliest  operation  required  for  it  in  the  specifications. 

This  procedure  is  not  necessary  for  the  network  above.  All  MESSAGES 

passed  by  CC I N require  an  ACKNOWLEDGEMENT  message  response  to  be  passed  by 

CC_0UT.  All  HANDOVER  messages  clearly  require  a TRACK INITIATION  message 

to  be  passed  by  DATA_RECORD.  The  above  network  completely  describes  the 
only  conditions  where  these  responses  are  generated  within  the  DPS.  A 
TRACK_TERMINATION  message  is  passed  by  DATA_RECORD  in  response  to  an  input 
TERMINATION  message  passed  by  CC_IN.  However,  this  case  represents  only 
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one  condition  where  a TRACK_TERMINATION  message  is  generated  by  the  DPS. 

The  remaining  conditions  will  occur  on  other  R_NETs.  But,  all  of  these 
responses  have  one  thing  in  common.  Each  is  a single  MESSAGE  passed  through 
a specific  OUTPUT_INTERFACE  in  response  to  a given  MESSAGE  or  class  of 
MESSAGES  passed  by  a single  specific  INPUT_INTERFACE.  These  are  examples 
of  "synchronous  processing":  the  input  is  joined  to  the  output  by  a 
direct  path  of  processing  steps,  and  none  of  the  data  used  are  modified  by 
processing  performed  on  any  other  path. 

In  the  context  of  R_NETs,  logical  connectivity  is  maintained,  not 
only  by  a continuous  path  through  one  R_NET,  but  perhaps  through  additional 
R_NETs  by  means  of  EVENTS.  An  EVENT  is  an  alternate  means  for  enabling  an 
R_NET.  A single  logical  path  is  formed  by  the  path  leading  to  the  event 
on  the  enabling  R_NET  and  continuing  on  a path  on  the  enabled  R_NET.  Such 
paths  represent  "synchronous  processing"  only  if  none  of  the  data  used  are 
modified  by  an  independent  path. 

"Asynchronous  processing"  is  a more  complex  concept  to  grasp.  This 
type  of  processing  is  implicit  when  two  R_NETs  are  related  by  data,  but 
without  the  "logical  connectivity"  represented  by  flowing  tokens.  An 
example  involving  three  simple  R_NETs  will  serve  to  illustrate  the  basic 
forms  of  "asynchronous  processing."  The  example  is  defined  in  Figure  3-7. 

Whenever  a subsystem  SSI  passes  an  XIN  message  through  the  DPS  inter- 
face SSI _I N , the  R_NET  named  X_VALUE  is  enabled.  This  R_NET  accepts  the 
data  NEW_X  in  the  message  and,  if  NEW_X  satisfies  certain  conditions,  up- 
dates the  value  of  a global  variable,  X,  to  the  value  of  NEW_X.  Whenever 
a second'  subsystem,  SS2,  passes  a YIN  message  through  the  interface  SS2_IN 
the  R_NET  named  Z_VALUE  is  enabled.  This  R_NET  accepts  the  data  Y in  the 
message  and  adds  it  to  the  current  value  of  X defined  in  the  data  base  to 
form  Z (defined  as  a global  variable  for  this  example).  The  value  of  Z is 
contained  in  the  ZOUT  message  sent  to  SS2  via  SS2_0UT,  but  is  also  retained 
in  the  DPS  because  Z is  defined  as  global  data.  Further,  a third  R_NET 
named  ZZ_VAIUE  periodically  enables  itself,  to  compute  Z , by  means  of  an 
event  on  its  own  structure  and  an  associated  time  delay.  The  value  of  Z 
which  is  used  is,  of  course,  that  which  is  current  in  the  data  base.  There 
is  no  specific  order  of  enablement  required  of  the  R_NETs. 
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Examination  of  this  system  shows  that  the  values  of  Z and  Z depend 

not  only  on  the  inputs  X and  Y (or  their  previous  values),  but  also  on  the 

sequence  of  enablement  of  the  R_NETs.  Thus,  within  a given  time  interval, 

there  is  not  a one-to-one  correspondence  between  the  latest  values  of  X and 

2 

Y and  the  latest  values  of  Z and  Z . For  that  matter,  no  such  correspondence 

. ? 
exists  between  Z and  Z . 

A simple  example  of  "asynchronous  processing"  in  the  TLS  example 
might  be  the  use  of  radar  clock  time.  The  sole  function  of  the  R_NET 
called  RADAR_TIMING  is  to  accept  timing  inputs  from  the  radar  and  update 
the  global  variable  RADAR_CLOCK.  If  another  R_NET  needed  radar  time,  it 
would  use  the  value  of  RADAR_CLOCK.  This  value  does  not  reflect  the  cur- 
rent time,  but  rather  the  time  at  which  the  radar  formed  the  message  which 
was  last  accepted  by  the  R_NET  called  RADAR_TIMING. 

The  major,  and  most  complicated,  example  of  "asynchronous  processing" 
in  the  TLS  is  the  relationship  between  radar  returns  and  the  next  set  of 
radar  commands.  Synchronous  tracking  would  require  that  data  from  the  last 
radar  return  from  an  object  be  used  to  produce  the  next  succeeding  radar 
order  related  to  that  object.  Asynchronous  tracking  allows  use  of  the  last 
data  available  in  the  OPS,  even  though  more  current  data  may  be  coming 
from  the  radar.  Asynchronous  tracking  allows  less  stringent  DP  response 
times,  better  time-line  usage,  and  permits  gradually  degraded  response  with 
increased  system  load.  Synchronous  tracking,  on  the  other  hand,  places 
stringent  constraints  on  the  DP  which  lead  to  saturation  and  loss  of  track 
under  relatively  light  loads. 

The  definition  of  an  asynchronous  processing  concept  is  subtle  and 
often  difficult.  No  cookbook  solutions  can  be  offered  for  this  creative 
process.  First,  the  R_NETs  must  be  traced  both  forward  from  the  input 
interfaces  and  backward  from  the  output  interfaces.  The  data  and  logical 
connectivity  t.o  fill  the  gaps  between  must  then  be  added  through  an  active 
and  creative  engineering  thought  process.  Note  that  SREM  does  provide  a 
framework  of  organization  which  fosters  consistency,  and  ultimately  leads 
to  a simulation  which  can  detect  errors  of  concept. 
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3.1.7  Entity  Definition 


I 


One  of  the  most  powerful  concepts  used  in  SREM  is  that  of  an  "entity". 
This  concept  allows  a clear  expression  cf  "he  role  of  the  DPS  requirements 
in  the  same  operation,  and  the  RSL  facilities  provided  tend  to  enforce  that 
perspective.  An  "entity"  is  simply  a thing,  or  category  of  thinqs,  in  the 
external  world  about  which  the  DPS  must  collect,  process,  and  maintain  data. 
Entities  are  closely  tied  to  the  reasons  for  the  existence  of  the  system  and 
its  DPS.  They  are  usually  implicit  in  the  wording  of  the  originating 
speci fications . 

For  instance,  the  basic  purpose  of  the  TLS  is  to  gather  data  on  the 
position  and  velocity  of  designated  objects  within  its  detection  range,  and 
to  predict  the  position  and  velocity  of  those  objects  at  some  future  time. 
This  suggests  that  "objects"  might  be  an  entity.  However,  "designated 

objects"  would  be  a better  candidate,  because  the  TLS  is  not  expected  to 

2 

detect  any  objects  other  than  those  the  C System  orders  it  to  track. 

Considering  the  TLS  as  a whole,  this  might  be  a reasonable  choice. 

But  the  focus  is  on  the  DPS  and  it  is  not  "aware"  of  objects  because  it 
does  not  perceive  them  directly.  The  radar  performs  the  sensor  functions. 
Thus,  the  DPS  is  only  aware  of  what  the  radar  perceives  as  objects  and 
reports  to  the  DPS.  The  nomenclature  of  the  DPSPR  calls  these  "images". 
Further  reading  of  the  DPSPR  shows  that  much  of  the  DPS  processing  is  con- 
cerned with  the  proper  classification  of  these  images,  and  eventual  elimi- 
nation of  those  which  do  not  correspond  to  real  objects  (ghosts),  or  which 
are  redundant  images  of  the  same  object.  During  the  time  that  an  image  is 
considered  an  "image  in  track",  a certain  instance  of  data  items  must  be 
maintained  in  the  DPS  and  be  associated  with  the  proper  image.  When  the 
DPS  decides  that  the  image  is  probably  redundant  or  a ghost,  or  should  drop 
track  on  that  image  for  other  reasons,  the  DPS  must  maintain,  for  a time, 
a different  set  of  data  about  that  image. 

Thus,  there  is  a general  category  of  things  called  "images"  which  are 
of  importance  to  the  DPS.  In  SREM,  such  a category  is  called  an  ENTITY_ 
CLASS.  Hence,  for  TLS  an  ENTITY_CLASS  named  IMAGE  was  defined.  There 
are  two  types  of  IMAGE,  distinguished  by  the  different  data  associated  with 
each  type;  designated  as  IMAGE_IN_TRACK,  and  DROPPED_IMAGE.  Each  IMAGE  of 
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which  the  DPS  is  aware  has  an  instance  of  data  uniquely  associated  with  it. 
This  instance  may  be  composed  of  DATA  items  and  FILES.  The  composition  of 
the  instance  is  a function  of  ENTITY-TYPE  and,  by  definition,  should  be 
different  in  some  manner  from  at  least  one  other  type  in  the  class.  However, 
data  common  to  all  types  may  be  associated  with  the  ENTITY_CLASS  itself. 
Multiple  ENTITY_TYPEs  may  have  identical  data  associated  with  them.  These 
usually  imply  a transition  from  a common  earlier  state  (e.q.,  an  ENTITY_TYPE 
I is  set  to  either  ENT  I TY_TYPE  J or  ENTITY_TYPE  K depending  on  some  decision 
in  the  DPS). 

A second  ENTITY_CLASS  is  defined  in  TLS  for  radar  PULSEs.  The  pulse 
is  an  external  phenomenon  (an  electromagnetic  signal)  about  which  the  data 
processor  is  found  to  need  data,  and  which  exists  in  multiple  copies. 
Therefore,  it  satisfies  the  criteria  for  consideration  as  an  ENTITY_CLASS. 

The  fact  that  data  must  be  'remembered'  about  each  pulse  while  it  is  in 
transit,  and  the  required  data  themselves,  derive  from  the  IFS  through  the 
process  of  defining  the  functional  requirement.  Thus,  when  considering  the 
determination  of  range  to  the  target,  it  is  necessary  to  know  both  the 
start  time  of  the  range  gate  relative  to  the  start  of  transmission  and  the 
time  within  the  gate  that  the  signal  was  detected.  The  IFS  asserts  that  the 
radar  return  contains  the  time  within  the  gate;  the  start  time  of  the  gate 
must  therefore  be  'remembered'  by  the  data  processor  from  the  command  which 
gave  rise  to  the  return.  Thus,  the  data  required  on  a pulse  in  transit  have 
to  do  with  the  transmission  Darameters  relevant  to  different  pulse  waveforms. 
Consideration  of  data  and  logical  usage  differences  leads  to  the  definition 

of  four  ENTITYJYPES  named  T1_T2,  T3,  RETURNED ^PULSE , and  LOST_PULSE  within 

the  ENTITYJCLASS:  PULSE. 

3.1.8  The  Entity  Data  Hierarchy 

The  second  major  data  hierarchy  associated  with  SREM  is  the  "entity 
data  hierarchy"  depicted  in  Figure  3-8.  The  means  for  manipulating  data 
contained  in  an  entity  hierarchy  differ  from  those  used  with  the  interface 
hierarchies  described  in  Section  3.1.4. 

An  ENTITY_CLASS  is  COMPOSED  OF  one  or  more  ENTITY_TYPEs . If  there 
are  data  elements  common  to  all  ENTITY_TYPEs , then  the  ENTITY_CLASS  ASSOCIATES 
these  DATA  items  and  EILEs.  For  data  elements  specific  to  an  entity  type. 
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the  ENTITY_TYPE  ASSOCIATES  the  applicable  data  elements.  Once  again,  the 
DATA  item  is  the  lowest  element  in  the  hierarchy.  Each  FILE  CONTAINS  items 
of  DATA. 

The  chief  characteristic  of  the  entity  data  hierarchy  is  the  unique 
method  of  manipulating  data  which  is  implemented  in  RSL.  There  is  no  way, 
in  RSL,  for  a user  to  specify  that  a FILE  be  created  or  destroyed  by  an 
ALPHA.  FILES  may  only  be  modi fied  by  ALPHAS  (although  instances  in  files 
are  created  or  destroyed  in  the  BETA  models).  RSL  provides  a mechanism  to 
require  that  an  ALPHA  CREATES  or  DESTROYS  the  knowledge  that  an  instance 
of  an  ENTITY_CLASS  exists  in  the  environment.  When  an  ALPHA  creates  a new 
instance  of  an  ENTITY_CLASS , a new  instance  of  all  the  common  DATA  and 
FILES  ASSOCIATED  WITH  that  class  is  initialized.  The  ALPHA  may  then  assign 
proper  values  to  those  data  elements  through  its  BETA  definitions.  These 
data  elements  are  retained  throughout  the  life  of  the  instance. 

The  ALPHA  can  also  SET  the  ENTITY_TYPE.  When  this  is  done,  an  instance 
of  all  the  specific  DATA  and  FILES  ASSOCIATED  WITH  the  ENTITYJTYPE  is 
initialized  and  can  be  assigned  proper  values  within  the  BETA  definitions. 
When  the  instance  of  ENTITY_CLASS  is  SET  to  a new  ENTITY_TYPE,  the  specific 
data  elements  unique  to  the  old  type  are  destroyed  and  a new  instance  of 
data  elements  specific  to  the  new  type  is  initialized. 

As  the  data  processing  system  gathers  information  about  an  entity,  it 
may  first  identify  the  entity  as  being  of  one  ENTITY_TYPE,  and  then  another. 
Instances  of  a class  of  entities  thus  evolve  from  one  type  to  another,  but 
instances  of  one  class  (e.g.,  IMAGEs)  can  never  evolve  into  another  class 
(e.g.,  PULSEs).  Each  ENTITY_TYPE  therefore  COMPOSES  just  one  ENTITY_CLASS. 

An  instance  belongs  to  one  ENTITY_CLASS  after  an  ALPHA  CREATES  it,  and  it 
belongs  to  the  last  ENTITY_TYPE  to  which  an  ALPHA  SETS  it.  Eventually,  an 
ALPHA  may  destroy  (knowledge  of)  the  instance,  and  all  data  associated  with 
the  instance  vanish.  Although  the  RSL  statements  for  CREATES  and  DESTROYS 
refer  to  the  name  of  the  ENTITY_CLASS , the  operation  is  applicable  only 
to  a single  instance. 

This  concentration  of  the  requirements  for  creation  and  destruction 
of  knowledge  about  external  entities,  rather  than  the  mechanics  of  data 
structures,  allows  the  user  to  focus  on  the  requirements  for  the  DPS  as  a 
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part  of  the  system  in  which  it  is  embedded.  Otherwise,  the  tendency  would 
be  to  stray  into  process  design  issues,  such  as  when  to  set  up  FILES. 

As  was  done  with  MESSAGES  in  Section  3.1.3,  it  is  useful  to  diagram 
the  entity  data  hierarchies  before  coding  them  in  RSL.  Figure  3-9  shows 
diagrams  of  the  TLS  hierarchies  associated  with  the  two  ENTITYjCLASSes , 
PULSE  and  IMAGE.  When  the  definitions  are  stable  and  ready  to  enter  in 
the  ASSM,  the  entries  can  be  coded  in  RSL  as  shown  in  Figure  3-10  for  the 
ENTITY  CLASS:  IMAGE. 


ENTITY_CLASS : PULSE 
PULSE  TYPE 


TARGET _ID 

PULSE I D 

XMIT  START 


RECEIVE_ST0P 
T1  T2  XMIT 


ACCOUNTED 

FOR 


RECEIVE_STOP 
T3  XMIT 


ENTITY_CLASS:  IMAGE 
IMAGEJD 
ENTRY  TIME 


STATE 

LAST_PULSE 
COVARIANCE 
TRACK_RATE 
WAVEFORM 
IMAGE  IN  TRACK 


FILE:  TERMINATOR 
DROPPED J MAGE 


Figure  3-9  Entity  Hierarchy 
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EMIT  Y.C  L A 5S  : IMAGE. 


ASSOC I ATESl 

0 A T 4 | EMRY.TJME 
DATA}  IMAGE.lt). 

COMPOSED  OF  | 

EMITY. TYPE!  DROFpE  n_  j K aGE 
EM  I TY.T  YPE  « IMiEF»  IN.TRACK  , 
EMITY.typei  image.  in.  Track  , 
ASSOCIATES: 

D A T A i COVAPIAnCE 
UATAj  LAST. PULSE 
DATA:  STATE 

DATA:  TRAC*. PATE 

DATA:  w A V E P 0 R M , 

EM  I T Y_T  YPE  I DROPPED.  IMAGE . 

ASSOCIATES: 

pile:  terminator. 


Figure  3-10  RSL  Entity  Entry 


3.1.9  Independent  FILEs 

When  defining  processing  requirements,  there  may  be  a need  for  data 
sets  which  fit  in  neither  a transient  interface  data  hierarchy  nor  a per- 
manent entity  data  hierarchy.  These  should  have  the  properties  of  multi- 
ple instances  of  a data  item  or  data  group  and  which  either  need  to  be 
1)  retained  as  GLOBAL  data,  or  2)  ordered  in  some  particular  way,  or 
3)  temporarily  maintained  as  a class  of  data  meeting  some  selection 
criteria.  These  needs  can  be  satisfied  by  defining  an  independent 
FILE.  This  FILE  exists  in  the  DPS  at  all  time,  even  though  it  may 
be  empty.  Although  instances  in  the  file  can  be  created  and  destroyed 
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within  BETA  and  GAMMA  executable  descriptions  of  ALPHAS,  the  FILE  itself 
cannot  be  created  or  destroyed.  It  can  only  be  modified.  FILES  can  be 
INPUT  TO  ALPHAS  or  OUTPUT  FROM  ALPHAS  or  both. 

The  distinction  between  the  concepts  of  ENTITY_CLASS  and  independent 
FILE  often  may  appear  fuzzy.  The  key  distinction  is  that  a FILE  is  a set 
of  data,  an  ENTITY_CLAS$  is  the  subject  of  data. 

In  the  TLS,  there  exists  a file  of  constants  called  WAVEFORM_TABLE . 

This  FILE  is  part  of  the  site-adaptation  data  for  the  system,  and  is  inde- 
pendent of  real-time  input.  Two  other  TLS  examples  of  independent  FILEs 
are  those  called  COMMAND  and  CANDIDATE.  These  files  are  dynamic  (i.e., 
change  in  response  to  real-time  data).  Both  of  these  files  are  used  to 
select  instances  from  ENTITY_TYPE:  IMAGE_IN_TRACK  and  to  order  the  extracted 
data  to  determine  new  instances  of  ENTITY_CLASS:  PULSE.  Thus,  these  files 
are  part  of  the  data  bridge  between  the  two  ENTITY_CLASSes  in  TLS. 

3.1.10  Summary  of  Phase  1 

This  section  has  outlined  a general  procedure  for  defining  the  ele- 
ments needed  to  specify  the  requirements  for  the  DPS.  At  this  point  many 
of  the  requirements  definitions  are  gross  and  tentative.  The  constructs 
may  have  been  entered  into  the  ASSM  as  they  were  defined,  or  they  may  just 
exist  on  paper.  This  choice  is  up  to  the  user,  and  depends  upon  the  size 
and  nature  of  the  DPS  problem,  and  the  number  of  people  involved. 

The  following  "top  down"  sequence  of  steps  has  proved  to  be  the  most 
effecti ve : 

1)  Define  the  subsystems  relevant  to  the  DPS. 

2)  Define  the  interfaces  connecting  the  DPS  to  the  subsystems. 

3)  Establish  the  messages  passing  through  the  interfices,  and 
define  their  data  contents. 

4)  Develop  the  R NETs  originating  at  input  interfaces. 

5)  Construct  processing  steps,  tracing  backward  from  the  output 
interfaces  when  necessary. 

6)  Define  the  entities  of  concern  to  the  DPS,  and  the  associated 
data  hierarchies. 
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7)  Define  independent  files  as  necessary. 


k 


8)  Refine  the  R_NETs  and  create  new  ones,  as  needed,  to  link 
the  input  and  output  interfaces. 

Some  variation  on  this  sequence  may  be  appropriate  to  certain  problems,  but 
the  basic  principle  is  to  move  from  known  interfaces  to  internal  processing 
steps,  using  the  data  definitions  as  a vehicle. 

The  ALPHAS  defined  at  this  point  will  be  primitive,  and  will  reflect 
high  level  concepts  of  the  nature  of  the  processing.  In  Phase  3 (Section  3.3) 
they  will  be  modified,  and  expanded  into  subnets,  as  necessary.  But  first, 
Phase  2 (Section  3.2)  is  needed  to  consolidate  the  information  developed 
to  this  point  and  to  ensure  that  it  forms  a consistent  basis  for  detailed 
development. 


3.2  PHASE  2 - EVALUATION  OF  THE  KERNEL 


Before  completing  the  definition  of  the  functional  requirements 
structure,  it  is  prudent  to  enter  the  information  derived  in  Phase  1 
into  the  ASSM  and  check  the  results,  both  manually  and  with  the  aid  of 
Requirements  Analysis  and  Data  Extraction  (RADX)  procedures.  Therefore, 
all  information  from  the  paper  constructs  that  has  not  been  previously 
entered  should  be  loaded  into  the  ASSM.  This  nucleus  of  information, 
called  the  "kernel",  constitutes  the  minimum  needed  to  document  the  major 
elements  of  the  functional  requirements  definition. 

3.2.1  Data  Naming  Conventions 

RSL  has  been  designed  to  force  an  early  precision  of  thought  with 
respect  to  data  definition.  A single  item  of  information  may  require 
several  different  DATA  names  in  the  course  of  its  existence  in  the  system. 
These  are  applied  as  the  usage  of  the  information  and  its  properties  of 
transience  or  permanence  dictate.  Naming  is  a tedious  process,  and  may 
lead  to  a variety  of  awkward  names,  but  it  is  mandatory  in  the  development 
of  a coherent,  unambiguous  DPS  model.  While  the  RSL  translator  will  detect 
most  common  ambiguities  or  conflicts,  the  user  should  continually  refine 
his  understanding  of  the  data  flows  within  the  DPS  in  order  to  catch  more 
subtle  errors. 

The  entity  data  are  the  first  to  display  the  constraints  imposed  by 
RSL  naming  conventions.  In  general,  it  is  necessary  that  a data  element 
exist  in  only  a single  hierarchy;  the  sole  exception  is  that  it  may  exist 
in  multiple  MESSAGES.  Thus,  the  identifier  of  an  image  being  tracked  is 

both  the  TARGETJD  ASSOCIATED  WITH  PULSE  and  the  IMAGE ID  ASSOCIATED  WITH 

IMAGE.  The  two  values  are  the  same  when  the  TARGET_ID  is  assigned,  but 
note  that  the  destruction  of  an  instance  in  one  ENTITY_CLASS  is  unrelated 
to  the  existence  of  an  instance  of  any  other.  The  meaning  of  a single 
identifier,  if  the  IMAGE  instance  were  destroyed  while  the  PULSE  was  still 
•active,  would  be  indeterminate.  It  is  only  to  resolve  such  indeterminacy 
that  the  naming  rules  are  imposed;  here,  the  "same"  information  is  given 
different  names  for  the  two  occurrences  in  different  hierarchies. 

The  identifier  used  for  an  IMAGE  is  given  to  the  CC_RESPONSE  R_NET 
as  a HO  ID  (handover  identifier).  The  same  name  is  applied  to  a drop-track 
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command  when  a TERMINATION  message  is  sent,  and  also  any  of  three  MESSAGES 
through  the  DATA_RECORD  interface,  whenever  information  about  that  image  is 
updated.  However,  when  the  information  is  to  be  held  in  global  storage 
(such  as  for  an  entity),  a different  name  must  be  applied  (IMAGE_ID  for  the 
IMAGE  class,  TARGETJD  for  PULSE). 

3.2.2  Structural  Data  Definitions 

R_NETs  can  be  entered  into  the  ASSM  in  two  ways.  Using  REVS  in  the 
ONLINE  mode,  the  nets  can  be  entered  interactively  via  the  Anagraph  terminal 
at  the  ARC  facility.  Using  REVS  in  the  OFFLINE  mode,  the  nets  can  be  speci- 
fied by  an  input  deck  of  RSL  statements.  If  the  OFFLINE  mode  is  used,  cer- 
tain DATA  which  are  integral  to  the  R_NET  structure  must  be  defined  with 
appropriate  statements  before  the  set  of  statements  which  define  the 
STRUCTURE  of  the  R_NET  can  be  integrated.  Prior  data  definition  is  not 
necessary  if  the  Anagraph  terminal  is  used,  but  should  be  accomplished 
within  Phase  2 for  completeness  of  the  kernel. 

Structural  DATA  elements  include  those  winch  are  referenced  on  the 
network  STRUCTURE  in  FOR  EACH  or  SELECT  statements;  CONSIDER  statements 
associated  with  an  OR  node;  and  conditional  expressions  associated  with 
an  OR  node.  The  latter  two  types  are  called  "selection  variables."  Other 
DATA  which  should  be  defined  at  this  point  are  those  DATA  which  DELAYS  the 
occurrence  of  an  EVENT  or  ORDERS  a FILE. 

The  FOR  EACH  statement  may  be  absolute  or  conditional.  The  object 
upon  which  the  statement  operates  can  be  an  ENTITY_CLASS , ENTITY_TYPE,  or 
FILE.  While  the  FILE  is  usually  associated  with  cne  of  the  interface  or 
entity  hierarchies,  assumed  to  be  defined  previously,  some  FILES  may  exist 
independently  from  any  hierarchy,  as  discussed  in  3.1.9.  It  should  be 
verified  that  all  elements  used  in  FOR  EACH  and  SELECT  statements  are 
declared  in  the  ASSM  prior  to  entry  of  R_NET  definitions  which  use  them. 
Elements  used  in  the  condition  part  of  a conditional  FOR  EACH  must  be 
defined  as  discussed  below  for  selection  variables. 

Selection  variables  require  added  definition  at  this  point  because 
of  the  mechanics  of  the  RSL  translation  process.  In  addition  to  declara- 
tion of  the  DATA  name,  its  TYPE  must  be  identified.  Further,  if  the  TYPE 
is  ENUMERATION,  the  RANGE  of  values  must  be  defined  before  the  R_NET 
STRUCTURE  can  be  translated. 
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While  not  mandatory,  it  is  recommended  that  the  LOCALITY  and  USE 
attributes  for  selection  variables  also  be  defined  at  this  point,  and  be 
verified  manually  because  REVS  consistency  analysis  does  not  include  DATA 
referenced  in  conditional  expressions.  Thus,  the  software  cannot  detect 
definition  errors  until  data  flow  analysis  or  SIMGEN  executions.  Figure 
3-11  shows  RSL  inputs  which  are  typical  TLS  examples  of  selection  variable 
definition. 


DATAj  hope. 

LOCAL ITVj  GLOBAL. 
range*  "ENGAGED, STANDBY", 
TYPE!  ENUMERATION, 

USE ! do  TH  t 
OUTPUT  FWOMJ 


DATA:  la$t_pulse, 

LOCAL  I T V * GLOBAL  , 
TYPE*  PEAl, 

USE*  BOTH. 


DATA:  TRACK_RATE, 

LOCAL  ITT:  GLOBAL, 

Type:  peal, 
us£j  both. 


DATA;  Tf.PF, 

LOCAL  ITT:  LOCAL, 
TYPE!  PEAL, 

USE:  Both. 


Figure  3-11  RSL  Data  Entry 

The  identification  of  selection  variables  within  a system  is  usually 
straightforward.  These  are  simply  the  decision  parameters  whose  value 
determines  whether  one  series  of  processing  steps  or  an  alternate  series 
is  to  be  executed.  When  multiple  message  types  pass  through  an  INPUT_ 
INTERFACE,  the  type  identifier  contained  in  the  message  is,  with  no  known 

exceptions,  a selection  variable  (e.g.,  COMMANDED  in  the  CC I N interface 

hierarchy).  Since  the  data  input  to  an  ALPHA  is  fixed,  and  since  each 
message  type  implies  either  different  data  content  or  different  processing, 
there  must  exist  at  least  one  unique  ALPHA  for  each  message  type. 
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3.2.3  Entering  R_NETs  in  the  ASSM 

The  required  information  about  each  R_NET  is  its  name,  enabling 
mechanism,  and  structure.  In  the  current  version  of  REVS,  names  assigned 
to  R_NETs,  SUBNETS,  and  ALPHAs  must  be  unique  within  the  first  eight 
characters.  For  all  other  RSL  elements,  names  must  be  unique  over  a field 
of  sixty  characters,  which  is  the  maximum  name  length  allowed. 

The  enabling  mechanism  of  an  R_NET  is  either  a single  INPUT-JNTERFACE 
or  one  or  more  EVENTS.  If  a message  passing  through  an  interface  is  the 
mechanism,  then  the  first  statement  in  the  R_NET  STRUCTURE  is  an  INPUT_INTERFACE 
name  declaration.  In  the  case  of  EVENTS,  the  EVENT  name  does  not  appear  in 
the  STRUCTURE  of  the  enabled  R_NET.  However,  it  appears  in  the  STRUCTURE 
of  the  enabl i ng  R_NET  at  the  appropriate  point. 

When  the  R_NET  is  entered  into  the  ASSM  via  card  input,  data  elements 
which  appear  in  the  STRUCTURE  must  be  predefined  in  the  ASSM.  These  da.ta 
are  discussed  in  3.2.2.  The  R_NET  STRUCTURE  is  discussed  in  below. 

3.2.4  The  STRUCTURE  of  an  R_NET 

Flows  through  the  system  are  specified  in  RSL  as  Requirements  Networks 
(R_NETs).  R_NET  flow  STRUCTURES  consist  of  nodes,  which  specify  processing 
operations,  and  the  arcs  which  connect  them.  The  processing  nodes  are  ALPHAS, 
which  are  specifications  of  functional  processing  steps,  and  SUBNETS,  which 
are  specifications  of  processing  flows  at  a lower  level  in  the  hierarchy. 

The  processing  no Jes  are  single-entry,  single-exit. 

In  addition  to  the  simple  sequential  flow  which  may  be  represented  by 
connecting  this  type  of  node,  more  complex  flow  situations  are  expressible 
in  RSL  by  the  use  of  structured  nodes  which  fan-in  and  fan-out  to  specify 
different  processing  paths.  These  nodes  are  variations  of  AND  and  OR  nodes, 
and  include  an  OR  with  a CONSIDER  statement.  The  REVS  Users  Manual  contains 
an  extensive  discussion  of  these  structural  elements.  Also,  the  TLS 
examples  in  the  Appendix  show  the  actual  format  of  various  structures. 

Indentation  is  used  in  the  STRUCTURE  declaration  to  facilitate  reading. 
When  entering  the  declaration  on  cards,  using  REVS  in  the  OFFLINE  mode, 
the  indentation  format  typified  by  the  REVS  output  examples  in  the  appendices 
should  be  followed.  This  is  not  mandatory,  but  it  is  strongly  recommended 
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in  order  to  check  the  output  against  the  input.  In  this  way,  the  user 
can  quickly  detect  where  REVS  has  interpreted  the  STRUCTURE  in  a different 
way  than  intended. 

In  addition  to  describing  the  processing  flow  of  an  R_NET,  the  STRUC- 
TURE declaration  may  also  serve  to  declare  the  existence  of  the  named  ALPHAS 
and  SUBNETS.  The  STRUCTURE  of  any  SUBNET  should  also  be  declared  at  this 
time.  Further  definition  of  the  attributes  of  ALPHAS  will  take  place  in 
Phase  3. 

If  Anagraph  or  CALCOMP  plots  of  the  structures  are  desired,  graphic 
data  must  be  entered  for  each  R_NET.  Graphic  coordinates  may  be  entered 
from  the  Anagraph  terminal  or  generated  by  a RADX  PLOT  command.  The 
Anagraph  plots  are  useful  while  working  interactively  at  the  terminal.  The 
CALCOMP  plots  are  more  useful  for  permanent  retention  and  for  documentation, 
as  shown  in  Appendix  G. 

3.2.5  Checking  the  Kernel  with  the  Aid  of  RADX 

As  part  of  the  auditing  process,  it  is  useful  here  to  define  a set  of 
RADX  directives  which  assist  in  determining  the  completeness  of  entries 
into  the  ASSM.  Two  operations  are  recommended  which  are  simple,  but 
reveal ing : 

1)  APPEND  R_NET  STRUCTURE,  ENABLED. 

LIST  R_NET. 

2)  APPEND  SUBNET  STRUCTURE,  REFERRED. 

LIST  SUBNET. 

These  directives  generate  a listing  of  the  R_NETs  with  their  structures  and 
enabling  events  or  interfaces.  Since  each  R_NET  requires  a structure,  and 
an  enabling  condition,  any  failure  of  that  class  is  detectable  here. 
Similarly,  the  correctness  (agreement  with  intention)  of  EVENT  naming  may 
be  confirmed. 

While  it  is  possible  to  confirm  the  structures  by  inspection  of  the 
RADX  output,  reading  the  equivalent  diagrams  (generated  by  RNETGEN)  is 
generally  simpler;  since  they  are  equivalent  representations,  either  the 
CALCOMP  illustration  or  the  RADX  listing  may  be  employed  for  the  purpose. 
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(Note  that  viewing  the  Anagraph  output  at  the  terminal  is  less  useful  since 
all  element  names  are  truncated  to  three  characters  and  since  branching 
criteria  are  not  immediately  displayed.) 

It  is  in  data  analysis  that  the  RADX  tools  are  most  useful  at  this 
stage.  Defining  two  hierarchies  for  data  output: 

HIERARCHY  FILES  = FILE  CONTAINS  DATA  DATA  INCLUDES  DATA. 

HIERARCHY  DATUM  * DATA  INCLUDES  DATA. 

It  is  desired  to  identify  the  DATA  items  and  the  FILEs  which  are  not  linked 
with  higher  data  levels  (entities,  or  messages).  One  way  derives  from  the 
following  definitions: 

SET  A = ALL  WITHOUT  ASSOCIATED. 

SET  B = A WITHOUT  MAKES. 

SET  C = B WITHOUT  CONTAINED. 

SET  D = C WITHOUT  INCLUDED. 

Now  the  RCL  (RADX)  directive:  LIST  B WITH  HIERARCHY  FILES  will  generate 
both  the  file  names  and  the  data  comprising  each  such  file  where  the  file 
is  not  associated  with  an  entity  and  does  not  make  a message.  Such  a free- 
standing file  should  be  a conscious  product  of  reguirements  engineering  and 
not  an  accident. 

Free-standing  DATA  may  be  extracted  by:  LIST  D WITH  HIERARCHY  DATUM. 
Note  that  the  HIERARCHY  DATUM  is  used  here  as  a convenience  to  limit  the 
output  to  the  names  of  the  top  data  level  not  constituting  part  of  a hier- 
archy; it  does  not  in  fact  cause  INCLUDED  DATA  to  be  output,  since  the  SET 
from  which  the  extraction  is  effected  (D)  has  no  members  which  are  INCLUDED 
in  any  DATA.  To  complete  tracing  of  the  data  hierarchies,  yet  another  SET 
would  have  to  be  defined  containing  the  DATA  extracted  by  LIST  D WITH  HIER- 
ARCHY DATUM,  and  that  SET  would  then  be  LISTed  with  HIERARCHY  DATUM. 

Typically,  free-standing  DATA  and  FILES  may  be  local  or  global  con- 
stants. Each  item  extracted  by  the  methods  outlined  above  should  be 
assessed  to  determine  whether  in  fact  it  should  be  isolated  or  is  properly 
a constituent  of  an  entity  or  interface  hierarchy. 


Finally,  the  following  HIERARCHies  may  be  defined,  and  each  may  be 
used  to  complete  the  RADX  directive:  LIST  ALL  WITH  HIERARCHY  . 

HIERARCHY  ENTITY  = 

ENTITY_CLASS  ASSOCIATES  DATA 
ENTITY_CLASS  ASSOCIATES  FILE 
ENTITYJCLASS  COMPOSED  ENTITY_TYPE 
ENTITY_TYPF  ASSOCIATES  DATA 
ENTITY_TYPE  ASSOCIATES  FILE 
FILE  CONTAINS  DATA 
DATA  INCLUDES  DATA. 

HIERARCHY  INFACE  = 

INPUTJNTERFACE  PASSES  MESSAGE 
MESSAGE  MADE  DATA 
MESSAGE  MADE  FILE 
FILE  CONTAINS  DATA 
DATA  INCLUDES  DATA. 

HIERARCHY  OUTFACE  = 

OUTPUTJNTERFACE  PASSES  MESSAGE 
MESSAGE  MADE  DATA 
MESSAGE  MADE  FILE 
FILE  CONTAINS  DATA 
DATA  INCLUDES  DATA. 

The  result  is  to  extract  from  the  ASSM  the  complete  kernel  of  the  require- 
ments, as  illustrated  in  Appendix  F. 

3.2.6  Summary  of  Phase  2 

This  phase  has  been  a period  of  consolidation,  between  the  initial 
definitions  of  Phase  1,  and  the  completion  of  those  definitions  in  Phase  3. 
Nonetheless,  the  end  of  Phase  2 is  an  important  milestone  in  the  total  effort. 

For  the  first  time,  the  kernel  of  the  requirements  construct  has  been 
loaded  into  the  ASSM  as  a whole.  Many  of  the  early  mistakes  and  inconsis- 
tencies will  be  detected  by  the  RSL  translator  during  the  entry  process. 

More  important,  the  requirements  engineer  can  now  use  tN»  facilities  of  the 
Requirements  Analysis  and  Data  Extractor  (RADX). 
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The  introductory  uses  of  RADX,  in  3.2.5,  will  be  built  upon  and 
expanded  in  Phase  3.  Eventually,  each  user  will  probably  compile  his  own 
library  of  RADX  procedures.  In  future  efforts  these  "off-the-shel f"  pro- 
cedures can  be  used  as  part  of  the  overall  evaluation  sequence. 


3.3  PHASE  3 - COMPLETION  OF  THE  FUNCTIONAL  DEFINITION 


The  work  through  Phase  2 has  provided  definition  of  the  higher-level 
elements  of  data  hierarchies;  definition  of  R_NETs,  their  STRUCTURES,  and 
their  enabling  events;  and  declaration  of  the  existence  of  ALPHAS  and  their 
place  in  the  R_NETs.  This  information  has  been  entered  into  the  ASSM  and 
has  been  subjected  to  various  forms  of  automated  analysis  and  review. 

It  now  remains  to  complete  the  definition  of  these  elements  to  pro- 
vide a basis  for  construction  of  an  executable  simulation.  Each  ALPHA  must 
be  defined  in  terms  of  its  data  transactions,  and  definition  of  all  DATA 
which  are  known  to  be  INPUT  TO  or  OUTPUT  FROM  an  ALPHA  must  be  completed. 

In  general,  the  DATA  which  can  be  described  at  this  stage  are  either  those 
global  to  multiple  R_NETs,  or  those  local  DATA  which  make  messages.  The 
need  for  additional  local  data  internal  to  the  R_NETs  will  be  discovered 
in  the  development  of  executable  descriptions  (Section  3.5).  At  that  time 
the  need  for  definition  of  lower  levels  of  the  existing  data  hierarchies 
may  be  apparent. 

During  this  process,  the  original  primitive  ALPHAS  will  often  need 
redefinition.  Additional  ALPHAS  can  be  added,  or  the  original  ALPHAS 
can  be  redefined  as  SUBNETS,  which  preserves  traceability  and  minimizes 
modification  of  the  R_NETs.  Occasionally,  the  STRUCTURE  of  the  net  may 
change,  or  new  nets  may  be  added,  as  the  processing  requirements  evolve. 

The  following  phases  will  be  devoted  to  construction  of  a functional 
simulation,  using  BETAs,  which  are  executable  descriptions  of  the  ALPHAs. 

It  should  be  emphasized  that  this  activity  develops  and  executes  a 
simulation  of  the  requirements  for  the  DPS  software,  not  of  the  software 
itself.  The  primary  goal  of  this  simulation  is  to  ensure  that  the 
functional  definition  of  requirements  are  complete  and  consistent. 

Since  the  major  interactions  of  the  R_NETs  have  been  defined  in  the 
previous  phases  (Sections  3.1  and  3.2),  it  is  now  possible  to  partition 
the  work  into  essentially  isolated  efforts  for  several  engineers.  Fach 
parcel  should  consist  of  one  or  more  R_NETs,  each  considered  by  a single 
engineer  or  group.  Since  the  relationships  amonq  R_NETs  have  already  been 
defined,  the  interactions  amonq  parcels  will  he  restricted  to  joint  agree- 
ment on  the  content  of  communications  (usually  individual  DATA)  between 
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pairs  of  engineers,  and  need  not  be  coordinated  extensively  over  the 
system  as  a whole.  The  sole  exception  to  that  rule  is  in  naming  conven- 
tions, where  a possibility  of  conflict  exists,  and  where  control  is  useful. 

3.3.1  Entity  Transitions 

Whenever  an  instance  of  an  ENTITY_CLASS  is  selected,  created,  or 
destroyed,  the  context  of  the  processing  flow  is  altered  significantly. 

To  clarify  the  flow,  each  such  operation  is  represented  as  a node  on  a 
STRUCTURE  (R_NET  or  SUBNET)  or  as  a relationship  on  an  ALPHA.  The  SELECT 
node  is  always  qualified  by  the  conditional  which  defines  the  instance  to 
which  subsequent  processing  refers;  the  selection  persists  until  another 
SELECT  or  FOR  EACH  node  is  encountered;  note  that  each  branch  of  processing 
is  assumed  to  be  completed  before  another  is  entered,  so  that  the  SELECTion 
of  an  instance  of  any  ENTITY_CLASS  need  be  performed  only  once  on  a branch 
(in  most  cases) . 

It  must  be  remembered  in  defining  the  nodes  and  relationships  which 
generate  entity  transitions  (i.e.,  SELECT,  FOR  EACH,  CREATES,  DESTROYS,  and 
SETS)  that  each  is  interpreted  to  mean  that  the  transition  is  always 
effected  when  the  node  is  reached.  Thus,  an  ALPHA  which  SETS  an  ENTITY_ 
TYPE  will  always  do  so.  Where  the  interpretation  is  the  same  for  such  a 
relationship  as  for,  say,  INPUTS,  REVS  enforces  it  even  more  strongly.  That 
is,  REVS  will  report  on  the  error  (but  will  build  a simulator  using  the 
data)  when  an  undeclared  DATA  input  is  used  in  a BETA  or  GAMMA;  however, 

REVS  will  provide  a transition  of  ENTITY_TYPE  if  and  only  if  the  SETS 
relationship  is  declared.  The  transition  will  be  for  exactly  the  instance 
selected  at  the  time  the  related  ALPHA  is  encountered  on  the  net. 

The  R_NET  for  CC_RESPONSE  developed  in  Section  3.1  is  illustrated 
again  in  this  section  with  entity  operations  expressed  on  the  net.  Com- 
parison with  the  figures  in  Section  3.1.6  will  show  the  added  detail  and 
information  provided  by  the  added  nodes.  After  modifying  the  structures 
to  reflect  the  entity  transitions,  analysis  of  the  kernel  (Section  3.2.5) 
should  be  repeated. 
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3.3.2  Data  Transactions 

There  was  an  initial  concept  of  the  DATA  which  were  to  be  INPUT  TO 
and  OUTPUT  FROM  each  ALPHA  when  the  ALPHA  was  placed  in  the  STRUCTURE  of  an 
R_NET.  Now  the  preliminary  gross  concept  must  be  precisely  defined. 

During  this  process,  additional  data  definitions  or  more  detailed  definition 
of  existing  hierarchies  may  be  necessary. 

As  the  data  transactions  and  the  hierarchy  transitions  discussed  in 
Section  3.3.4  are  developed,  the  processing  steps  within  each  ALPHA  which 
transform  the  inputs  into  the  required  outputs  must  be  considered.  The 
conceptual  ideas  of  the  procedure  may  be  noted  in  the  ASSM,  in  English  text, 
or  using  the  RSL  DESCRIPTION  attribute.  A structured  English  description 
of  the  processing  can  later  be  used  for  reference  during  development  of  the 
BETAs  which  are  written  in  PASCAL.  If,  at  this  point,  it  becomes  apparent 
that  significant  logical  branching  must  occur  within  the  ALPHA,  the  ALPHA 
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can  be  redefined  as  a SUBNET.  In  this  manner  the  logical  structure 
requirements  are  made  explicit  in  the  STRUCTURE  definition  of  the  SUBNET 
and  new  ALPHAs  are  defined  to  specify  the  operations  within  this  structure. 

As  an  example  of  the  thought  process  involved  with  data  transactions, 
consider  the  ALPHA  named  INITIATE_TRACK  (later  renamed  TRACK_INITIATE) . 

This  ALPHA  is  on  the  CC_RESPONSE  R_NET  and  is  on  the  processing  path 
activated  by  a HANDOVER  message  of  type  HANDOVERJMAGE  (=COMMAND_ID) . 

Since  COMMANDED  was  used  as  a selection  variable  in  order  to  reach  the 
ALPHA,  it  is  unlikely  that  it  will  be  used  within  the  ALPHA.  However,  the 
remaining  data  content  of  the  MESSAGE  must  be  used  within  the  ALPHA  because 
there  are  no  other  ALPHAs  on  this  path  which  could  use  the  unique  content 
of  this  message  type.  These  DATA  are  H0_ID,  I N I T I ALLSTATE  , and  I N I T I AL_ 
COVARIANCE.  Thus,  these  DATA  will  be  defined  as  INPUT  TO  the  ALPHA. 

.TRACKJNITIATE  must  FORM  a MESSAGE  to  be  PASSED  BY  the  OUTPUTJNTER- 

FACE  named  DATA_RECORD.  It  is  clear  that  TRACK I N I T I AT  I ON  is  the  proper 

message  to  be  formed  and  passed.  Thus,  the  DATA  in  that  message  must  be 
OUTPUT  FROM  the  ALPHA.  These  are  HOJD,  INITI AL_STATE , and  T I ME_0F_I N I T I A- 
TION.  The  first  two  DATA  are  present  in  the  inputs,  but  the  third  is  not. 

The  remaining  DATA  item  for  the  MESSAGE  is  the  time  of  arrival  of 

the  incoming  command  at  CC I M . REVS  maintains  a DATA  item  called  CL0CK_ 

TIME  which  is  set  to  the  simulator  time  at  the  initiation  of  each  R_NET, 
and  which  is  not  to  be  altered  by  any  processing.  (Since  time  is  not 

advanced  during  the  "execution"  of  an  R_NET,  CLOCK ^T IMF  is  not  updated 

along  a net.)  Note  that  CLOCK_TIME  is  a DATA  item  predefined  within  the 
RSL  NUCLEUS  in  the  ASSM:  a second  DATA  item  is  maintained  by  REVS,  FOUND, 
which  is  TRUE  if  the  last  SELECT  operation  retrieved  an  instance  satis- 
fying the  selection  criterion.  Neither  element  may  ever  be  OUTPUT  by  an 
ALPHA.  Either  element  may  be  INPUT  TO  an  ALPHA,  as  CLOCK_TIME  is  INPUT  TO: 
TRACKJNITIATE  for  assignment  as  TIMEJ3FJNITIATI0N,  which  is  then  OUTPUT 
for  the  MESSAGE. 

What  additional  processing  is  needed  in  TRACKJNITIATE?  Its  primary 
function  is  to  use  the  data  provided  in  the  HANDOVER  message  to  initiate 
track  on  a new  image.  Thus,  it  is  logical  to  assume  that  the  ALPHA  CREATES 
a new  instance  of  ENTITY  CLASS:  IMAGE,  and  designates  it  as  ENTITY JYPE: 


IMAGE I N_TRACK.  Hence,  the  ALPHA  should  output  the  DATA  associated  with 

this  ENTITY_CLASS  and  ENTITY_TYPE.  These  are:  IMAGEJD,  ENTRY_TIME , 

STATE,  COVARIANCE,  TRACK  RATE,  WAVEFORM,  and  LAST_PULSE. 

It  is  also  reasonable  to  assume  that  TRAC K I N I T I AT E should  assign 

the  values  of  H0_ID,  CLOCK_TIME,  INITIAL JSTATE , and  I N I T I AL_C0VAR I ANCE  to 
IMAGEJD,  ENTRY JIME,  STATE,  and  COVARIANCE,  respectively.  These  assign- 
ments are  unconditional,  as  no  choice  criteria  are  indicated  in  the  speci- 
fications. For  the  moment,  it  is  sufficient  to  defer  the  question  as  to 
the  origin  of  TRACK_RATE,  WAVEFORM,  and  LAST_PULSE,  and  simply  to  define 
them  as  OUTPUT  FROM  the  ALPHA.  Figure  3-12  shows  the  declaration,  in  RSL, 
of  all  the  data  transactions  of  TRACKJNITIATE.  Note  that  a DATA  item, 
DATA_RECORDJYPE  is  defined  for  the  output  message  consistent  with  MESSAGE 
definition  requirements  discussed  in  Section  3.1.3.  From  our  concept  of  the 
processing,  it  appears  that  the  original  ALPHA  is  adequate  and  no  additional 
ALPHAS,  or  redefinition  as  a SUBNET,  are  required. 

alpha:  tp  Ac  K_  INITIATE* 

InPuTSj 

DATaj 

data:  wfi_in 

DATA!  INlTlAL.ChVAPI ANCE 
JATAj  INITIAL, STATE . 

OUlPLTSI 

data:  covariance 

DATA:  OAT A_REC0Rn_T YPF 

DATAj  ENTRV^TIME 
DATA:  IMA&F_ID 

data:  state 

DATA:  time, OF, INITIATION 

OATAj  TRAC*, RATE 

DATA:  WAVEFORM, 

Figure  3-12  RSL  Initial  ALPHA  Entry 

3.3.3  RADX  Evaluation  of  Data  Transactions 

In  addition  to  confirming  entry  of  attributes  and  relationships  through 
RADX  directives  (e.g.,  LIST  ALPHA.),  it  is  now  useful  to  extract  the  specific 
cases  which  are  potential  errors,  or  are  at  least  anomalous  to  the  point 
where  they  demand  special  attention.  For  example,  it  is  possible  for  an 
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ALPHA  either  to  have  no  INPUTS  or  to  have  no  OUTPUTS,  or  even  to  have 
neither,  without  its  being  erroneous;  but  the  normal  case  is  that  each  ALPHA 
will  have  both.  Having  completed  the  RSL  declarations  about  the  ALPHAS  at 
this  stage,  it  is  meaningful  to  define  the  following  SETS  for  RADX  analysis 
of  the  ALPHA  definitions  existing  in  the  ASSM  at  this  point. 

1)  SET  A = ALPHA  WITHOUT  INPUTS. 

2)  SET  B = ALPHA  WITHOUT  OUTPUTS. 

3)  SET  C = A WITHOUT  OUTPUTS. 

Remembering  that  the  declaration  of  a SET  generates  a count  of  its  members, 
it  may  be  discovered  that  SET  C is  empty;  this  would  indicate  that  each 
ALPHA  has  either  an  INPUTS  or  an  OUTPUTS  relationship  (or  both).  However, 
in  TLS,  several  ALPHAS  have  neither.  In  particular,  the  error-processing 
elements  (C2_ERR0R_PR0CESSING)  are  required  to  exist,  but  have  no  other 
specifications;  therefore,  they  have  no  accesses  defined.  Similarly,  the 
ALPHA;  ACKNOWLEDGE  exists  solely  so  that  the  ACKNOWLEDGEMENT  message  may 
be  FORMED;  since  the  processing  modifies  no  DATA,  the  ALPHA  has  neither 
INPUTS  nor  OUTPUTS. 

In  general,  an  ALPHA  without  INPUTS  is  one  which  operates  on  the  sys- 
tem as  a whole,  rather  than  on  information  retained  by  the  DPS.  For  example, 
ENGAGEMENT_INITIATION  and  TERM_ENGAGEMENT  accomplish  their  purposes  by  the 
occurrence  of  the  appropriate  message;  only  the  value  of  the  selection  var- 
iable (COMMANDED)  is  required  to  initiate  them,  and  these  ALPHAs  execute 
independently  of  the  state  of  the  global  data  base. 

In  general,  an  ALPHA  with  INPUTS  but  without  OUTPUTS  is  a signal  of 
a specification  problem.  Trivially,  the  only  reason  for  acquisition  of  DATA 
for  processing  is  that  it  may  effect  some  generation  of  DATA  for  OUTPUT. 

To  construct  a valid  case  for  an  ALPHA  which  must  accept  INPUTS  but  is  not 
required  to  provide  OUTPUTS  has  not  yet  been  demonstrated. 
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In  addition  to  the  elementary  data  relationships,  each  ALPHA  may 
modify  DATA  within  hierarchies  in  a variety  of  ways.  Given  the  engineering 
concept  of  the  action  of  the  ALPHA,  it  is  possible  to  express  its  action  on 
the  hierarchies  in  terms  of  the  RSL  directives:  CREATES,  DESTROYS,  SETS, 
and  FORMS. 

There  are  two  fundamental  generative  operations  that  an  ALPHA  may 
express:  CREATES  and  FORMS.  They  declare  the  need  for  a new  instance  of  a 
named  ENTITY_CLASS,  or  for  a named  MESSAGE,  respectively.  In  response  to 
either  directive  it  is  required  that  the  specified  INITIAL_VALUEs  for  all 
associated  DATA  with  such  values  be  assigned.  This  is  done  automatically 

when  REVS  acts  upon  an  I N I T I AL VAL UE  definition.  If  an  INI1IAL_VALUE  is 

not  defined,  REVS  will  assign  a default  value  according  to  the  TYPE  of  the 
DATA.  These  values  are  (0,  0.0,  FALSE,  first  defined  value  in  the  RANGE) 
for  the  respective  types  (INTEGER,  REAL,  BOOLEAN,  ENUMERATION).  Once  the 
DATA  associated  with  the  instance  are  initialized,  they  may  be  assigned 
current  values  by  assignment  statements  within  the  BETA. 

When  an  instance  of  an  ENTITY_CLASS  is  CREATED,  the  ALPHA  which 
CREATES  the  instance  normally  SETS  the  ENTITY_TYPE.  Otherwise,  only  the 
DATA  and  FILES  common  to  all  types  in  the  class  can  be  defined.  As  the 
instance  persists  in  the  system,  its  type  will  evolve  (i.e.,  an  ALPHA  SETS 
it  to  a different  type).  The  ALPHAS  in  which  such  changes  are  effected  are 

normally  obvious  from  the  R_NET.  In  each  case,  such  an  ALPHA  SETS  ENT  I TY 

TYPE  to  the  appropriate  ENTITY  TYPE  name. 

For  example,  the  discussion,  in  3.2.2,  of  the  ALPHA  named  TRACK_ 
INITIATE  revealed  that  the  ALPHA  performs  all  of  the  actions  above.  It 
FORMS  the  MESSAGE  named  TRACKJNITIATION.  Also,  it  first  CREATES  an  in- 
stance of  ENTITY_CLASS:  IMAGE,  then  SETS  the  instance  to  ENTITY_TYPE : IMAGE 
IN_TRACK.  Figure  3-13  shows  how  these  declarations  are  written  in  RSL. 
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ALPHA | TPACK_INITIATEt 

creates: 

En T I t Y— CL  *SS*  ImaGE  . 
forms  : 

MESSAGE:  TRACK-INITIATION, 

SETSI 

ENTITY-TYPE*  IMAGE-IK_TrACK, 


Figure  3-13  RSL  Addtional  ALPHA  Entry 

When  there  is  no  further  need  for  the  DPS  to  retain  data  related  to  a 
specific  instance  of  an  ENTITY_CLASS,  or  to  be  aware  of  the  existence  of  the 
instance  in  the  external  world,  the  "instance  of  the  ENTITY_CLASS"  can  be 
DESTROYED  BY  an  ALPHA.  The  disposition  of  a PULSE  in  TLS  depends  on  whether 
it  is  a LOST_PULSE  or  a RETURNED_PULSE.  For  a LOST_PULSE,  the  instance  is 
DESTROYED  (no  longer  of  value)  after  it  has  been  accounted  for  in  the  ALPHA 
named  SETJLOST.  For  a RETURNED_PULSE , the  instance  is  not  destroyed  until 
it  has  also  been  accounted  for  in  the  ALPHA  named  SET_PULSE.  Note  that,  In 
this  case,  the  Instance  of  ENTITYJCLASS:  PULSE  can  be  DESTROYED  in  either 
way,  but  not  before  it  has  been  accounted  for  in  both.  This  is  because  the 
R_NETs  execute  independently  of  one  another,  and  no  specific  sequence  is 
otherwise  required. 

3.3.5  Further  Data  Definition 

Through  the  previous  work  many,  if  not  most,  of  the  DATA  in  the  system 
have  been  named,  and  their  relationships  with  ALPHAS  have  been  established. 
In  order  to  complete  the  requirements  specification  and  construct  an  execut- 
able simulation,  however,  the  "attributes"  of  the  DATA  must  be  defined. 

The  three  principal  attributes  are  LOCALITY,  TYPE,  and  USE. 


3-49 


3. 3. 5.1  Locality 


DATA  and  FILES  may  have  different  required  accessibility  in  the  sys- 
tem. The  range  of  accessibility  of  an  item  is  denoted  by  the  attribute 
LOCALITY,  which  may  have  values  of  LOCAL  or  GLOBAL.  Items  of  DATA  or  FILEs 
which  are  LOCAL  are  associated  with  the  R_NETs  in  which  they  are  used  and 
are  unknown  outside  of  these  R_NETs.  LOCAL  DATA  exist  only  during  the 
invocation  of  the  R_NET  to  which  they  are  LOCAL.  They  are  created  when 
the  flow  token  is  generated  at  R_NET  ENABLEment  and  cease  to  exist  when 
the  flow  token  leaves  that  R_NET.  ALPHAs  which  use  LOCAL  DATA  and  FILEs 
may  appear  on  more  than  one  R_NET;  therefore,  it  is  possible  for  a single 
DATA  item  or  a FILE  to  be  LOCAL  to  more  than  one  R_NET.  However,  these  are 
different  instances  of  the  DATA  or  FILE  which  have  no  relation  to  each 
other;  each  has  a completely  separate  existence,  controlled  by  the  R_NET 

in  question.  Note  that  data  local  to  an  R_NET  are  given  their  I N I T I AL 

VALUES  at  initiation  of  that  net. 

GLOBAL  DATA  and  FILES  are  accessible  by  more  than  one  R_NET  and  exist 
over  more  than  one  R_NET  invocation.  DATA  and  FILEs  which  are  ASSOCIATED 
with  an  ENTITY_TYPE  or  an  ENTITYjCLASS  are  tied  to  the  entity  instances  to 
which  they  belong.  They  are  created  when  the  instance  is  CREATED  and  persist 
until  the  instance  is  DESTROYED.  Items  which  are  not  ASSOCIATED  with  entities 
are  permanently  housed  in  the  global  data  base,  and  may  exist  throughout  the 
duration  of  the  system. 

Thus,  DATA  and  FILEs  which  belong  to  an  interface  data  hierarchy  (e.g., 
MESSAGE)  are  implicitly  LOCAL  and  required  by  REVS  to  be  LOCAL.  DATA  and 
FILEs  associated  with  an  entity  data  hierarchy  are  implicitly  GLOBAL  and 
required  by  REVS  to  be  GLOBAL.  DATA  and  FILEs  not  associated  with  either 
type  of  hierarchy  have  not  implicit  locality.  Even  if  the  locality  is  not 
explicitly  defined,  an  item  exists  in  the  data  base  at  all  times,  accessi- 
ble to  the  R_NETs,  but  in  an  "undefined"  state.  Failure  to  declare  LOCALITY 
can  produce  weird  consequences  later,  if  the  element  involved  has  not  im- 
plicit locality.  On  the  other  hand,  declarations  are  not  needed  if  the 
locality  is  implicit.  At  best  they  are  redundant,  and  at  worst  they  are 
misleading  because  REVS  overrides,  during  simulation  generation  (SIMGEN), 
any  declaration  in  the  ASSM  which  conflicts  with  the  implicit  locality. 
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While  it  is  possible  to  manually  identify  which  DATA  and  FILES  need 
LOCALITY  declarations,  and  which  do  not,  it  is  easier  and  less  risky  to  use 
a RADX  procedure  to  do  this.  One  such  procedure  is  discussed  in  3.3.6. 


For  the  remaining  items  which  need  a LOCALITY  declaration,  the  source 
of  the  item  should  be  considered.  If  an  independent  DATA  item  or  FILE  is 
not  OUTPUT  FROM  some  ALPHA  on  an  R_NET  previous  to  its  being  INPUT  TO  some 
other  ALPHA  on  that  net,  it  cannot  be  LOCAL  to  that  R_NET.  If  the  item  is 
OUTPUT  FROM  an  ALPHA  on  some  other  R_NET,  the  item  is  GLOBAL  unless  an  error 
has  been  made  in  the  INPUTS  and  OUTPUTS  definitions.  In  many  cases  the 
correct  locality  is  obvious.  The  inability  to  find  a source  for  an  inde- 
pendent item  on  any  of  the  R_NETs  indicates  a specification  deficiency. 

If  a DATA  item  or  FILE  is  OUTPUT  FROM  an  ALPHA  on  a net  other  than 
that  which  uses  the  item  as  input,  the  indicated  LOCALITY  is  GLOBAL.  If 
no  other  R_NET  generates  the  item,  then  the  origin  of  the  item  is  on  a 
previous  execution  of  the  R_NET  which  uses  it. 

If  the  ALPHA  which  OUTPUTS  an  item  does  not  clearly  precede  the  ALPHA 
which  INPUTS  it,  care  must  be  taken  to  ensure  that  the  item  has  an  initial 
value.  The  default  values  assigned  by  REVS  in  the  absence  of  an  INITIAL_ 
VALUE  declaration  were  described  in  3.3.4.  If  these  are  unacceptable,  the 
user  must  declare  the  correct  INITIAL_VALUE.  Note  that  "clearly  precede" 
in  the  context  above  means  that  the  ALPHA  which  OUTPUTS  the  item  is  either: 

1)  before  the  ALPHA  which  INPUTS  it,  on  the  same  path  within  an  R_NET,  or 

2)  precedes  the  ALPHA  which  INPUTS  the  item  on  a single  path  linked  by 
enabling  EVENTS  (generally  without  DELAYS). 

3. 3.5.2  Type  and  Range 

Other  details  about  DATA  must  be  known  for  purposes  of  simulation. 

BETAs  and  GAMMAs  are  executable  code  which  are  meaningful  only  if  more  is 
known  about  the  DATA  than  should  be  stated  as  a requirement.  In  addition, 
a hierarchy  of  DATA  may  be  stated  as  a requirement,  but  a functional  simu- 
lation (using  BETAs)  may  employ  DATA  only  part  way  down  the  hierarchy.  That 
is,  the  simulation  may  use  one  DATA  item  to  represent  a part  of  an  entire  hier 
archy.  The  characteristics  of  this  summarized  DATA  must  be  stated  for  the 
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simulation  to  execute  using  the  RSL  USE  attribute.  Since  an  analytic 
emulation  (using  GAMMAs)  might  not  employ  the  same  DATA,  the  type  infor- 
mation for  BETAs  may  be  different  from  that  for  GAMMAs.  The  only  DATA  that 
can  be  used  in  the  BETAs  and  GAMMAs  and  have  their  values  communicated 
between  ALPHAS,  however,  are  those  whose  TYPE  has  been  defined. 

The  attribute  TYPE  contains  the  necessary  information  for  typing  of 
the  DATA.  This  attribute  may  have  values  REAL,  INTEGER,  BOOLEAN,  or  ENUMERA- 
TION. A DATA  item  with  type  ENUMERATION  corresponds  closely  to  one  with  a 
scalar  type  in  PASCAL;  that  is,  it  has  values  which  are  denoted  by  identi- 
fiers. The  legal  values  for  ENUMERATION  types  are  given  in  the  RANGE  attribute. 

The  TYPE  declared  need  not  correspond  to  that  of  the  actual  data  in 
the  real  DPS.  Rather,  it  should  be  chosen  to  reflect  the  purposes  of  the 
functional  and  analytic  simulations,  and  the  fidelity  required  in  those 
simulations.  For  instance,  in  the  real  DPS,  unique  alphanumeric  text  strings 
may  be  used  to  identify  objects.  If  these  are  an  open  set,  they  cannot  be 
represented  by  a DATA  element  with  TYPE:  ENUMERATION  because  that  defines  a 
closed  set.  However,  for  purposes  of  simulation,  the  DPS  property  of 
interest  is  the  ability  of  the  DPS  to  distinguish  between  unique  identifiers. 
Thus,  by  defining  the  identifier  as  TYPE:  INTEGER,  and  representing  each 
object  or  class  of  objects  by  a unique  integer  value,  a representation 
adequate  for  the  purposes  is  obtained. 

Similarly,  in  TLS,  identifiers  such  as  H0_ID,  IMAGE_ID,  and  RADAR_ 
0RDER_ID  are  represented  by  integers.  In  the  real  TLS  some  symbolic  code 
convention  would  probably  be  used.  In  like  fashion,  message  identifiers 
such  as  COMMANDED  which  form  a closed  set  are  represented  as  DATA  with 
TYPE:  ENUMERATION.  The  values  defined  are  for  explanatory  purposes.  The 
values  in  the  actual  TLS  would  certainly  be  different. 

Since  the  appropriate  TYPE  for  DATA  is  strongly  dependent  on  its  USE, 
the  choice  may  be  deferred  until  the  USE  attribute  has  been  determined. 
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3.3. 5.3  Use 


Further  qualification  of  the  use  of  a DATA  item  in  the  simulation 
is  given  by  the  attribute  USE.  The  value  of  this  attribute  may  be  BETA, 
GAMMA,  or  BOTH  denoting  that  the  data  item  is  the  lowest  level  in  the  data 
hierarchy  which  will  be  used  in  the  corresponding  simulation. 

Frequently,  even  the  first  declaration  of  a DATA  item  makes  clear 
its  USE  in  the  system.  For  example,  if  the  element  is  known  to  correspond 
to  a single  unit  of  information  (bit,  byte,  or  word)  in  implementable  soft- 
ware, then  it  is  probably  used  in  BOTH  beta  and  gamma  models.  Nor- 
mally, a selection  variable  will  be  in  this  class.  Similarly,  it  is  likely 
that  an  item  which  INCLUDES  others  in  the  detailed  modeling,  but  which  may 
be  treated  as  a whole  for  functional  modeling  will  have  USE:BETA.  It  is 
unlikely  that  any  element  with  USE  restricted  to  GAMMA  will  be  recognized 
at  this  stage  of  development,  since  its  declaration  would  be  primarily  in 
support  of  analytic  simulation;  the  exception  would  occur  if  a highly  de- 
tailed interface  specification  gave  low-level  DATA  definitions,  for  which 
higher  levels  would  suffice  in  a functional  model. 

For  example,  in  the  TLS  definition,  INITIAL_STATE  is  a single  DATA 
element  with  USE:BETA.  In  the  external  world  "state"  is  defined  by  a posi- 
tion vector,  a velocity  vector,  and  perhaps  an  acceleration  vector,  each 
with  three  components.  Such  detail  is  not  needed  for  the  functional  simu- 
lation. However,  an  analytic  simulation  has  need  for  these  elements.  Thus, 
eventually  each  of  the  components  will  be  defined  to  have  USE:  GAMMA. 
Similarly,  for  the  functional  simulation,  INITIAL COVARIANCE  can  be  repre- 

sented by  a single  element  with  USE:BETA.  Later,  its  matrix  components  can 
be  defined  with  USE: GAMMA  when  they  are  needed  for  analytic  simulation. 

3. 3. 5. 4 Values 

Values  are  the  ultimate  object  of  defining  DATA.  At  the  lowest  level 
in  a hierarchy  of  DATA  the  requirements  engineer  may  specify  the  attributes 
UNITS,  MAXIMUM_VALUE,  MINIMUM_VALUE,  I N I T I AL_VAL UE , and  RESOLUTION.  The 
attribute  UNITS  is  given  separately  from  the  various  types  of  values,  both 
to  rraintain  consistency  with  their  specification  and  to  enable  requirements 
r infers  to  indicate  the  minimum  possible  information  about  a DATA'S  value, 


r 
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its  UNITS.  In  nearly  all  cases  it  will  be  known  the  units  are  milliseconds 
or  microseconds  even  if  the  specific  value  has  not  yet  been  determined. 
Separating  UNITS  from  the  values  enables  phased  specification  of  the  best 
information  that  is  available  at  the  initiation  of  DATA  item  definition. 

Since  the  attributes  UNITS,  MAXIMUM_VALUE,  MINIMUMJ/ALUE,  and  INITIAL_ 
VALUE  are  not  vectors,  the  definition  of  different  UNITS  and  values  of  a DATA 
set  above  the  lowest  level  in  the  hierarchy  is  not  possible.  RESOLUTION 
describes  the  required  maximum  value  of  the  least  significant  bit  for  the  DATA 
in  units  described  in  the  UNITS  attribute. 

3.3.6  Evaluation  of  the  ASSM  Using  RADX 

The  Requirements  Analysis  and  Data  Extraction  (RADX)  function  of  REVS 
is  the  tool  used  to  investigate  the  state  of  the  Abstract  System  Semantic 
Model  (ASSM).  RADX  provides  commands  that  allow  the  performance  of  several 
functions : 

• Identification  and  listing  of  elements  in  the  ASSM  that  do 
or  do  not  meet  some  criterion. 

• Listing  of  ASSM  elements  in  such  a manner  as  to  be  suitable 
for  inclusion  in  requirements  documents. 

• Listing  of  RSL  element,  attribute,  and  relation  definitions. 

• Analysis  of  the  ASSM  to  identify  requirements  that  are 
ambiguous  or  inconsistent. 

RADX  can  be  used  to  extract  specific  data  for  analysis  and  to  detect 
inconsistencies  and  omissions  in  the  ASSM.  This  capability  is  also  available 
to  management  to  evaluate  progress  of  the  development  activity,  and  to  inde- 
pendent analysts  who  may  be  assigned  to  verify  the  results  of  the  require- 
ments engineer. 

The  following  subparagraphs  discuss  typical  uses  of  RADX  in  evaluating 
the  work  done  in  Phase  3,  and  in  identification  of  work  remaining  to  be 
accomplished.  These  examples  are  not  meant  to  be  comprehensive,  nor  are 
they  the  only  way  to  do  the  task.  A comprehensive  catalog  of  RADX  pro- 
cedures would  be  a very  thick  document;  also,  there  are  many  ways  to  do  a 
specific  extraction  task  effectively.  Other  examples  can  be  found  in  the 
REVS  Users  Manual.  The  purposes  here  are  to  suggest  some  of  the  possible 
uses  of  RADX,  and  to  encourage  further  creativity  with  the  REVS  facilities. 
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3. 3.6.1  RADX  Evaluation  of  Data  Origin  and  Usage 


1 


A DATA  item  may  exist  in  the  relational  data  base  in  any  of  the 
following  ways: 

1)  OUTPUT  BY  an  ALPHA; 

2)  INCLUDED  IN  a DATA  OUTPUT  BY  an  ALPHA; 

3)  CONTAINED  IN  A FILE  OUTPUT  BY  an  ALPHA;  or 

4)  MAKE  a MESSAGE  which  is  PASSED  BY  an  INPUTJNTERFACE. 

Included  in  the  last  category  are  DATA  INCLUDED  in  DATA  which  MAKES  such 
a MESSAGE  and  DATA  CONTAINED  IN  a FILE  which  MAKES  such  a MESSAGE. 

RADX  is  used  to  extract  exceptions  to  the  above  rules,  since  they  con- 
stitute apparent  cases  of  'creative  memory'  --  data  extractable  from  the 
global  data  base  which  never  need  to  be  entered.  A legitimate  case  of 
creative  memory  is  a constant  with  a defined  INITIAL_VALUE;  in  fact,  DATA 
constants  are  properly  defined  in  just  such  a manner.  But  any  non-constant 
data  item  which  fits  in  none  of  the  above  categories  is  an  apparent  error, 
and  worthy  of  detailed  analysis.  (Note  that  a DATA  element  which  is  never 
INPUT  TO  an  ALPHA  and  which  does  not  MAKE  a MESSAGE  which  is  PASSED  BY  an 
OUTPUT_INTERFACE  is  also  worthy  of  scrutiny,  and  may  be  similarly  analyzed 
at  this  stage.  Among  the  DATA  which  will  properly  be  detected  at  this  step 
are  those  REFERRED  by  an  R_NET--  e.g.,  selection  variables.) 

With  the  aid  of  the  hierarchy  definitions  in  3.2.4, RADX  procedures 
can  be  constructed  to  isolate  the  DATA  described  above.  First  RADX  commands, 
which  are  used  in  both  cases,  are  defined  as: 

SET  INALPH  = DATA  THAT  IS  INPUT  BY  ALPHA. 

SET  OUTALPH  = DATA  THAT  IS  OUTPUT  BY  ALPHA. 

The  additional  commands  below  will  provide  a listing  of  DATA  INPUT  TO 
an  ALPHA  which  does  not  have  an  INITIAL  VALUE,  and  is  not  in  a MESSAGE 
PASSED  BY  an  INPUT_INTERFACE,  and  which  is  not  OUTPUT  FROM  some  ALPHA  on 
some  R NET. 
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SET  INMSG  = ALL  IN  HIERARCHY  INFACE. 

SET  INDATA  = INMSG  AND  DATA. 

SET  INOUT  = INALPH  MINUS  OUTALPH. 

SET  INOUT  = INOUT  MINUS  INDATA. 

SET  INOUT  = INOUT  WITHOUT  I N I T I AL__VAL UE . 

LIST  INOUT  WITH  HIERARCHY  DATUM. 

If,  Instead,  the  commands  shown  below  are  used,  a listing  of  DATA 
which  is  OUTPUT  from  an  ALPHA  and  not  INPUT  TO  an  ALPHA  and  not  in  a MESSAGE 
PASSED  BY  an  OUTPUT JNTERFACE  will  be  generated. 

SET  OUTMSG  = ALL  IN  HIERARCHY  OUTFACE. 

SET  OUTDATA  = OUTMSG  AND  DATA. 

SET  OUTIN  = OUTALPH  MINUS  INALPH. 

SET  OUTIN  = OUTIN  MINUS  OUTDATA. 

LIST  OUTIN  WITH  HIERARCHY  DATUM. 

3 . 3 . 6 . 2 RADX  Evaluation  of  File  Activity 

In  3.3.2  the  interpretations  when  a FILE  is  INPUT  TO  and/or  OUTPUT 
FROM  an  ALPHA  were  presented.  RADX  commands  can  be  used  to  isolate  various 
INPUT  combinations  for  verification.  The  following  are  useful  examples: 

SET  A = FILE  WITH  INPUT. 

SET  B = FILE  WITH  OUTPUT. 

SET  C = A OR  B. 

SET  D = FILE  MINUS  C. 

SET  E = B MINUS  A. 

SET  F = A MINUS  B. 

SET  G = A AND  B. 

Set  D consists  of  FILES  which  are  neither  INPUT  TO  nor  OUTPUT  FROM 
an  ALPHA. 

Set  E consists  of  FILEs  which  are  only  OUTPUT  FROM  some  ALPHA.  Given 
that  additions  were  made  to  the  FILE  for  some  purposes,  then  the  only  valid 
purpose,  other  than  for  INPUT  TO  some  ALPHA,  is  for  items  which  MAKE  an 
output  MESSAGE.  The  following  RADX  commands  provide  a listing  of  the 
remaining  which  do  not  MAKE  an  output  MESSAGE  and  which  should  be  checked 
for  errors. 
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SET  H = E MINUS  OUTMSG. 

LIST  H. 

Set  F consists  of  FILES  which  are  only  INPUT  TO  some  ALPHA.  This 
indicates  that  the  FILE  instances  are  accessed,  and  possibly  deleted,  within 
the  ALPHA,  i.e.,  the  BETA  or  GAMMA  description.  Since  the  FILE  is  not 
OUTPUT  FROM  an  ALPHA,  it  cannot  originate  within  the  DPS.  Therefore,  it 
must  appear  in  an  input  MESSAGE.  The  following  RADX  commands  provide  a 
listing  of  the  remaining  items  which  do  not  MAKE  an  input  MESSAGE  and 
which  should  be  checked  for  errors. 

SET  I = F MINUS  INMSG. 

LIST  I. 

Set  G consists  of  FILEs  which  are  both  INPUT  TO  and  OUTPUT  FROM  some 
ALPHAs,  not  necessarily  the  same  ALPHA.  These  FILEs,  together  with  the 
ALPHAs  which  operate  on  them,  can  be  extracted  by  the  following  commands. 

APPEND  FILE  INPUT,  OUTPUT. 

LIST  G. 

This  listing  should  be  examined  to  ensure  that  the  FILEs  are  operated 
upon  as  intended.  Particular  attention  should  be  given  to  ALPHAs  which 
INPUT  and  OUTPUT  the  same  FILE.  It  is  these  ALPHAs  which  either  modify  the 
instances  within  a FILE,  or  add  new  instances  when  an  appropriate  one  cannot 
be  found. 

3. 3. 6. 3 RADX  Evaluation  of  Entity  Activity 

It  is  also  useful  to  verify  that  ENTITY_CLASSes  and  ENTITY_TYPEs  are 
manipulated  appropriately  within  the  system.  Each  ENTITY_CLASS  must  be 
CREATED  BY  some  ALPHA.  Each  ENTITY_CLASS  should  be  DESTROYED  BY  some  ALPHA. 
If  it  is  not  destroyed,  there  must  be  a valid  reason  for  retaining  the 
ASSOCIATED  DATA  or  FILEs.  Further,  each  ENTITY_TYPE  within  an  ENTITY_CLASS 
must  be  SET  BY  some  ALPHA.  The  members  of  the  following  sets  represent 
apparent  deviations  from  these  rules  and  should  be  examined. 

SET  A = ENTITY_CLASS  WITHOUT  CREATED. 

SET  B = ENTITY_CLASS  WITHOUT  DESTROYED. 

SET  C = ENTITY  TYPE  WITHOUT  SET. 
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The  following  hierarchy  is  useful  to  determine  the  actions  on  each 
ENTITY_CLASS  in  the  system. 

HIERARCHY  ENTITY_CHECK  = 

ENTITY_CLASS  CREATED  BY  ALPHA 

ENTITY_CLASS  COMPOSED  ENTI TY_TYPE 
ENTITY ^TYPE  SET  BY  ALPHA 

ENTITY__CLASS  DESTROYED  BY  ALPHA. 

The  following  RADX  command  will  provide  a structured  listing  of  each 
instance  of  the  hierarchy  suitable  for  further  analysis. 

LIST  ALL  WITH  HIERARCHY  ENT  I TY_C:  iEC K . 

3. 3. 6. 4 RADX  Evaluation  of  Data  Attributes 

Data  extraction  can  be  of  major  support  in  development  of  the  execut- 
able description,  used  in  BETAs  and  GAMMAs,  although  it  is  not  a major  con- 
tributor to  assessment  of  the  result.  The  fact  that  RADX  cannot  penetrate 
the  contents  of  a BETA  or  GAMMA  to  determine  its  consistency  with  declara- 
tions of  relationships  and  attributes  is  of  little  significance,  since  the 
consistency  and  completeness  are  thoroughly  analyzable  with  the  static 
analyzers,  and  since  the  crucial  test  of  simulation  generation  is  then 
executable. 

One  of  the  key  operations  at  this  stage  of  specification  development 
is  defining  the  LOCALITY,  USE,  and  TYPE  of  all  DATA  required  for  functional 
simulation.  LOCALITY  is  the  easiest  of  the  attributes  to  specify: 

1)  Using  the  definitions  of  3.2,  LIST  ALL  WITH  HIERARCHY 
ENTITY  generates  a collection  of  GLOBAL  DATA; 

2)  Using  these  definitions,  LIST  ALL  WITH  HIERARCHY  INFACE  and 
LIST  ALL  WITH  HIERARCHY  OUTFACE  generates  a collection  of 
LOCAL  DATA; 

3)  LIST  B WITH  HIERARCHY  FILES  generates  the  collection  of 

DATA  CONTAINED  IN  FILEs  which  are  not  linked  to  higher  levels. 
Since  each  such  file  is  inherently  either  local  or  global  in 
scope,  all  CONTAINED  DATA  have  the  same  LOCALITY  as  their 
parent;  and 

4)  LIST  D WITH  HIERARCHY  DATUM  Identifies  the  top  level  of 
DATA  which  are  not  linked  into  higher  levels.  Each  such 
item  is  then  assigned  a LOCALITY,  which  is  also  the  value 
assigned  to  any  DATA  item  INCLUDED  in  that  top  level. 
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Since  the  system  provides  an  override  of  any  LOCALITY  declaration  for  ASSO- 
CIATED DATA  or  those  which  MAKEs  a MESSAGE,  any  LOCALITY  provided  by  the 
user  would  be  at  least  redundant,  and  at  worst  misleading,  however,  REVS 
will  identify  these  conditions  during  SIMGEN  by  issuing  Error  Messages. 
Therefore,  it  is  recommended  that  each  DATA  item  and  FILE  generated  by  (1) 
and  (2)  above  be  checked  to  ensure  that  no  LOCALITY  is  declared.  Similarly, 
it  is  best  to  declare  the  LOCALITY  for  each  FILE  derived  from  (3),  and  then 
to  omit  LOCALITY  for  each  FILE  derived  from  (3),  and  then  to  omit  LOCALITY 
for  each  DATA  item  obtained.  Finally,  each  DATA  item  obtained  in  (4)  is 
assigned  a LOCALITY,  and  the  same  LOCALITY  is  assigned  to  each  DATA  item 
included  in  it. 

Data  extraction  also  supports  assigning  USE  to  the  DATA  items.  Define 
SET  A = DATA  WITHOUT  INCLUDES.  Each  item  in  that  set  must  have  USE:  GAMMA 
or  BOTH.  It  is  given  USE  BOTH  exactly  if  it  is  to  be  a part  of  the  BETA 
model  for  some  ALPHA.  For  each  item  with  USE: BOTH,  no  DATA  above  it  in  the 
hierarchy  can  have  a USE  assigned.  Note  that  USE:B0TH  and  USE:GAMMA  may 
be  applied  only  to  the  lowest  level  of  DATA  defined.  Once  it  is  determined 
that  a given  lowest-level  DATA  item  will  not  be  included  in  the  functional 
model,  an  item  above  it  in  the  hierarchy  must  be  assigned  USE-.BETA.  That 

item  may  be  anywhere  above  the  one  with  USE:GAMMA,  except  that  it  cannot 
also  INCLUDE  (either  directly  or  through  a chain  of  INCLUDES)  any  element 
with  USE: BOTH. 

By  defining  a SET  A = DATA  WITH  USE,  the  engineer  determines  the  items 
requiring  TYPE.  It  is  not  mandatory  at  this  stage  to  TYPE  DATA  which  are  to 
be  used  only  analytically,  so  that  the  subset  required  for  functional  simu- 
lation can  be  obtained  through  SET  B = A WITHOUT  USE  = GAMMA.  Through 
examination  of  the  STRUCTURES  and  BETAs,  the  TYPE  of  each  such  item  is 
defined,  and  enumerated  DATA  are  also  assigned  RANGE. 

Note  that  it  is  at  least  misleading,  and  sometimes  likely  to  induce 
errors,  to  define  attributes  for  elements  which  do  not  require  them.  Thus, 
a LOCALITY: LOCAL  declaration  for  an  item  ASSOCIATED  WITH  an  ENTITY_TYPE 
would  be  overridden  by  REVS,  but  would  be  entered  into  the  ASSM  and  would 
appear  to  the  reader  of  the  specification  to  control  the  DATA  item.  Such 


3-59 


— nr 


a condition  would  degrade  legibility  of  the  document,  and  should  be  avoided. 
The  data  extractor  can  be  used  to  determine  if  any  over-specification  of 
this  sort  has  been  attempted. 

3. 3. 6. 5 RADX  Data  Flow  Analysis 

The  final  static  evaluation  of  the  functional  requirements  specifi- 
cation is  conducted  using  the  Data  Flow  Analysis  capability  of  REVS.  This 
capability  detects  the  incorrect  use  and  assignment  of  information  that 
flows  through  an  R_NET,  incomplete  and  ambiguous  conditions  for  making 
branch  decisions,  and  illegal  references  to  SUBNET  structures. 

Information  is  identified  as  being  incorrectly  used  if  there  is  a 
condition  which  requires  that  it  be  INPUT  to  an  ALPHA  node,  RECORDED  by  a 
VAL I DAT 1 0N_P0 1 NT  node,  PASSED  by  an  OUTPUT JNTERFACE  node,  or  used  for 
making  a decision  at  an  OR  node  and  there  is  no  specification  that  estab- 
lishes a value  for  the  information  prior  to  the  node  which  uses  it.  In- 
formation is  considered  to  have  an  established  value  if  it  has  an 

INITIAL_VALUE , is  PASSED  by  an  INPUT INTERFACE , is  OUTPUT  by  an  ALPHA,  or 

is  a member  of  an  identified  FILE  or  ENTITY. 

The  assignment  of  information  that  cannot  be  used  is  detected  when 
an  ALPHA  OUTPUTS  information  and  the  information  is  reassigned  before  being 
used  by  a predecessor  ALPHA,  information  that  is  part  of  a MESSAGE  that 

PASSES  an  INPUT I NTERFACE  is  not  referenced,  or  a MESSAGE  is  FORMed  that 

cannot  PASS  an  OUTPUTJNTERFACE. 

The  branch  conditions  of  a CONSIDER  OR  node  are  tested  to  insure 
that  they  are  unambiguous  and  exhaustive.  When  DATA  with  TYPE  ENUMERATION 
is  considered,  a check  is  made  to  see  that  all  possible  values  of  the 
DATA  specified  in  the  RANGE  altitude  are  contained  in  one  and  only  one  of 
the  branch  expressions  that  label  the  outward  branches  from  the  node.  For 
the  case  that  the  considered  element  is  an  ENTITY_CLASS , the  test  is  made 
that  all  ENTITY_TYPEs  which  COMPOSE  the  ENTITY__CLASS  are  represented 
exactly  once  in  the  branch  expressions  and  there  is  only  ENTITY_TYPE  in 
the  expressions  that  compose  the  class. 

Partially  re.ioininq  AND  constructs  and  partially  rejoining  OR  con- 
structs are  prohibited  by  RSL  within  a single  net  structure.  However, 
these  illegal  constructs  can  occur  when  a SUBNET  containing  a non-rejoining 
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logic  construct  is  referenced  within  another  net  at  a point  where  the 
reference  is  part  of  a rejoining  construct.  The  Data  Flow  Analyzer 
accesses  each  reference  to  a SUBNET  to  identify  the  occurrence  of  this 
type  of  error. 

3.3.7  Summary  of  Phase  3 

This  section  has  outlined  a general  procedure  for  completing  the 
definition  of  the  functional  requirements  for  a DPS.  The  following  steps 
were  accomplished: 

• The  data  transactions  of  each  ALPHA  were  defined. 

• The  hierarchy  transitions  performed  by  each  ALPHA,  if 
any,  were  defined. 

• The  user  has  redefined  ALPHAS  into  SUBNETS,  has  added 
ALPHAS,  and  has  modified  R_NET  STRUCTURES  if  the  Phase 
2 baseline  was  inadequate. 

• The  user  has  evolved  a clear  concept  of  the  processing 
done  within  each  ALPHA,  as  a starting  point  for  develop- 
ment of  BETAs. 

t The  definition  of  all  necessary  DATA  and  FILE  attributes 
has  been  completed,  to  the  extent  possible  without 
developing  BETAs  and  GAMMAs. 

• The  completeness  and  consistency  of  the  ASSM  has  been 
analyzed  and  verified  with  the  aid  of  RADX  capabilities. 

t The  REVS  Data  Tlow  Analyzer  has  verified  the  loqical  DATA 
flow  and  connectivity. 
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3.4  PHASE  4 - COMPLETION  OF  MANAGEMENT  AND  CONTROL  INFORMATION 


Traceability  is  a feature  of  the  specification  supporting  its 
management,  rather  than  one  reguired  for  its  technical  guality  per  se. 
Therefore,  the  reguirements  for  traceability  are  established  in  the  manage- 
ment volume;  however,  they  are  addressed  here  in  terms  of  reguirements  and 
technigues  necessary  for  their  entry  in  the  ASSM. 

3.4.1  Originating  Requirements 

The  originating  requirements  for  a software  specification  are  most 
commonly  contained  in  higher-level  specifications.  In  general  (depending 
on  management  decision)  each  identifiable  software  requirement  in  each 
higher-level  specification  will  be  called  out  as  an  ORIGINATING_REQUIREMENT 
in  the  ASSM.  The  DESCRIPTION  attributed  to  an  ORIGINATING_REQUIREMENT  may 
be  a literal  excerpt  of  the  source,  or  may  be  an  interpretation,  again  at 
management  discretion.  Note  that  ORIGINATING_REQUIREMENTs  in  REVS  do  not 
trace  to  one  another,  however,  an  OR  I G I NAT I NG_REQU I REMENT  may  be  INCORPO- 
RATED IN  a higher  level  requirement  of  which  it  is  a part.  The  lowest 
level  of  requirements  to  which  a DECISION  or  specification  element  traces 

should  be  entered  as  the  OR I G I NAT  I NG REQU I REMENT . Appendix  H illustrates 

the  structuring  of  OR I G I NAT I NG ^REQU I REMENT  using  the  INCORPORATES  and 

INCORPORATED  IN  relationships. 

3.4.2  Sources 

There  may  be  sources  of  information  which  define  specifics  of  the 
software  requirements,  but  which  are  not  specifications  in  themselves.  For 
example,  a table  of  constants,  or  a book  defining  a standard  atmosphere 
model  may  be  referenced  in  the  source  specifications  or  applied  by  the 
requirements  engineer  in  developing  the  software  specification.  Such  a 
SOURCE  is  also  recorded  in  the  ASSM,  since  it  DOCUMENTS  some  feature  of 
the  required  processing.  Note  that  a SOURCE  may  be  changed  during  develop- 
ment of  either  the  specification  or  the  software;  when  such  a change  occurs, 
its  impact  on  the  specification  may  be  followed  through  use  of  the  DOCUMENTS 
relationship. 
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A SOURCE  may  also  DOCUMENT  an  ORIGINATING_REQUIREMENT,  where  its 
interpretation  is  significantly  different.  The  collection  of  requirements 
in  a specification  document  should  be  traceable  to  that  SOURCE  to  support 
control  of  changes  when  the  specification  is  modified;  thus  the  SOURCE 
is  the  name  of  the  document  from  which  an  ORIGINATING_REQUIREMENT  is  taken. 
When  the  SOURCE  document  is  changed  (as  in  a specification  revision),  the 
use  of  SOURCE  can  expedite  tracking  the  influence  of  the  change  on  the 
software  requirements.  (In  a later  section  of  this  report,  the  concept 
of  a PERFORMANCE_REQUIREMENT  is  developed.  The  specification  serves  as 
a SOURCE  for  the  collection  of  PERFORMANCE_REQU IREMENTs  in  the  same  sense 
as  for  a collection  of  ORIGINATING_REQUIREMENTs . ) 

The  RSL  element  VERSION  is  used  to  document  a particular  configuration 
of  the  system  requirements  definition.  VERSION  is  used  to  trace  data  base 
elements  which  IMPLEMENTS  a particular  VERSION  DOCUMENTED  by  a particular 
SOURCE.  Appendix  H illustrates  the  use  of  these  elements  and  relationships 
to  document  contents  of  the  ASSM. 

3.4.3  Decisions 

As  was  noted  in  3.1.5,  the  process  of  developing  the  DPS  requirements 
may  expose  system  issues  which  cannot  be  resolved  immediately  in  a formal 
manner,  but  which  may  have  significant  impact  on  the  direction  of  further 
work.  Each  such  issue  is  recorded  in  the  ASSM  as  a DECISION  which  is  TRACED 
FROM  the  ORIGINATING_REQUIREMENT(s)  either  directly  or  through  other 
DECISIONS.  As  each  issue  is  encountered  it  should  be  given  a DECISION 
name,  and  entered  in  the  ASSM  with  at  least  its  key  attributes:  a statement 
of  the  PROBLEM,  the  recognized  ALTERNATIVES,  and  the  CHOICE  among  them  which 
was  made  to  allow  work  to  proceed.  When  the  CHOICE  is  reviewed  by  system 
engineering,  its  correctness  can  be  confirmed,  or  the  implications  of  any 
revision  can  be  assessed  through  analysis  of  those  elements  which  are  TRACED 
FROM  that  DECISION.  Paragraph  3.1.5  gives  an  example  of  the  input  needed 
to  state  one  of  the  TLS  issues. 
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3.4.4  Relating  to  Sources 


The  relationships  TRACES  TO  and  DOCUMENTS  have  been  defined  to  link 
elements  of  requirements  definitions  to  their  sources.  Each  element  of  the 
ASSM  should  be  TRACED  FROM  its  ORIGINATING_REQUIREMENT(s ) either  directly 
or  through  DECISIONS  which  may  be  TRACED  FROM  the  ORIGINATING^  REQUIREMENT. 
In  general,  the  ORIGINATING_REQUIREMENT  may  be  entered  into  the  ASSM  before 
their  traceability  is  developed  (i.e.,  before  any  of  the  elements  have  been 
defined).  As  the  R_NETs  are  built  and  as  the  other  elements  are  entered, 
their  links  with  any  ORIGINATING_REQUIREMENT  may  be  recorded  through  the 
TRACES  TO  relationship.  Whenever  a DECISION  is  encountered,  it  should  be 
entered  and  TRACED  FROM  its  source. 

Chronologically,  it  is  likely  that  the  first  entries  made  into  the 
ASSM  will  be  the  ORIGINATING_REQUIREMENTs ; some  SOURCES  may  also  precede 
development  of  the  R_NETs.  As  elements  are  developed,  DECISIONS  and 
additional  SOURCES  will  be  recorded,  and  at  least  some  TRACES  TO  and 
DOCUMENTS  relationships  will  be  provided.  Before  publication  of  the  speci- 
fication, management  may  require  element  audits  to  confirm  some  level  of 
completeness  of  tracing;  throughout  development  of  both  the  specification 
and  the  resulting  software,  the  linking  should  be  monitored  to  track,  in 
the  specification,  evolution  of  requirements.  Note  that  it  is  good  prac- 
tice in  requirements  engineering  to  explore,  through  the  data  extractor, 
the  impact  of  any  projected  modifications  to  requirements.  Particularly 
at  the  terminal,  it  is  convenient  to  query  the  ASSM  to  the  effect:  What 
if  the  DECISION  (name)  is  modified?  It  would  be  accomplished  LISTING  ALL 
WITH  an  appropriate  HIERARCHY  that  TRACED  FROM  that  DECISION,  then 
examining  the  attributes  of  each  element  that  was  so  related.  Judicious 
engineering  could  then  focus  on  the  requirements  with  the  least  impact  when 
examining  the  set  which  might  be  altered  to  reflect  a chanqe  in  the  soft- 
ware environment  (e.g.,  the  threat). 

3.4.5  Informative  Material 

Phases  1 through  3 have  discussed  the  development  of  the  technical 
content  of  the  ASSM.  In  addition  to  such  mandatory  material,  there  is  a 
family  of  supportive  information  which  miqht  be  recorded  for  any  elemen' 
Characteristic  of  that  family  is  the  DESCRIPTION,  an  attribute  which  allows 
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an  English-language  text  to  be  entered  (other  languages  might  be  used  except 
for  restrictions  due  to  character  sets)  to  explain  the  intent  of  the  element. 
Informative  material  is  not  constraining  on  the  process  designer,  and  is  not, 
in  fact,  a reguirement  subject  to  test;  it  is  merely  supportive  of  communi- 
cation between  the  requirements  engineer  and  both  his  peers  and  the  process 
designer.  The  need  for  any  informative  attribute  and  the  auditing  of  its 
entry  are  options  for  project  management,  and  are  discussed  in  the  management 
vol ume. 

3. 4. 5.1  Description 

A text  string  of  arbitrary  length  may  be  entered  to  describe  any 
element  of  the  ASSM  under  the  attribute  DESCRIPTION.  Even  where  the  element 
carries  a self-explanatory  name,  or  where  it  has  another  attribute  formally 
specifying  it,  a DESCRIPTION  is  usually  valuable.  For  example,  the  IMAGE_ID 
is  as  simple  a concept  about  an  IMAGE  as  can  be  promoted.  Nevertheless,  it 
would  be  useful  to  describe  it  as  being  assigned  from  the  HO I D of  the  ini- 
tiation message,  and  as  being  embodied  also  as  the  TARGETED  in  the  ENTITY 

CLASS : PULSE.  The  linkage  among  the  elements  is  defined  in  the  BETAs  of 
appropriate  ALPHAS,  of  course,  and  the  DESCRIPTION  is  not  binding.  But 
following  all  of  the  references  to  that  DATA  item  to  find  the  meaningful 
assignments  is  tedious  at  best,  where  the  DESCRIPTION  is  easily  absorbed. 


3. 4. 5. 2 Synonym 

A synonym  may  be  declared  and  EQUATED  TO  any  other  ele-  '•  for  clarity 
and  convenience.  Frequently,  the  SYNONYM  will  be  a short  nan  r a 
frequently  referenced  item,  so  that  at  least  some  of  the  references  are 
simplified;  occasionally,  the  naming  conventions  imposed  by  the  language 
will  prompt  the  use  of  a cryptic  element  name,  so  that  an  explanatory 
SYNONYM  is  desired. 

3. 4. 5. 3 Authorship 

In  the  current  REVS,  there  is  an  attribute  ENTERED_BY  which  permits 
the  author  of  information  about  an  element  to  record  his  name  and  the  date 
of  entry.  If  required,  that  operation  could  be  automated,  so  that  the 
attribute  would  become  a log  of  changes  made,  with  the  entry  provided  by 
the  system  whenever  a value  or  relationship  was  altered. 

3-65 


3 . 4 . 5 . 4 Complementary  Relationships 

Each  RSL  relationship  defines  a connection  between  two  elements; 
since  it  is  transitive,  it  has  a complement  which  simply  reverses  the 
subject  and  object.  When  information  is  extracted  from  the  ASSM,  both 
directions  of  the  relationship  are  derived  from  a single  link;  thus,  both 
the  relationship  and  its  complement  are  extracted,  and  redundant  but 
absolutely  consistent  information  is  obtained.  Since  consistency  is 
assured,  redundancy  is  constructive  in  providing  information  about  all 
relationships  on  an  element  under  examination.  Complementary  relationships 
as  a class  may  be  suppressed  in  extraction  through  an  APPEND  PRIMARY. 

3. 4. 5. 5 Structural  References 

In  the  structure  segment,  an  R_NET  makes  use  of  other  elements. 
Implicitly,  it  has  a relationship  to  each  such  element  which  appears  on 
its  STRUCTURE;  that  relationship  is  termed  REFERS,  and  is  implicit  in  use 
of  the  data  extractor  (RADX)  of  REVS.  The  relationship  and  its  complement 
are  visible  to  the  user  in  the  RADX  output,  but  are  entered  automatically 
and  implicitly  through  STRUCTURE  declaration,  not  through  the  conventional 
explicit  declarations. 
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3.5  PHASE  5 - DYNAMIC  FUNCTIONAL  VALIDATION 


Dynamic  validation  of  the  functional  requirements  entails  development 
of  functional  models  which  define  the  outputs  of  processing  in  terms  of  the 
inputs.  In  essence,  the  only  things  known  to  a data  processor  specification 
are  the  contents  of  its  interface  messages;  all  other  information  should  be 
defined  within  the  specification  in  terms  of  mathematical  operations  on  the 
input  data  stream.  Such  a definition  is  in  effect  a mathematical  model 
of  the  processing  operations  required.  Where  the  model  reflects  only  the 
gross  characteristics  of  the  transformation  required,  it  is  said  to  be 
functional;  such  models  in  REVS  are  termed  BETAS.  The  BETA  and  GAMMA 
representations  of  the  DPS  must  be  driven  by  a system  level  simulator  which 
SREM  assumes  to  exist,  due  to  the  prior  need  for  such  a simulator  in 
deriving  the  originating  specifications.  The  TLS  example  presumes  existence 
of  a System  Environment  and  Threat  Simulator  (SETS). 

3.5.1  Betas 

A BETA  is  a PASCAL  procedure  which  models  the  transformation  of  the 
DATA  and  FILES  INPUT  TO  an  ALPHA  into  the  DATA  and  FILEs  OUTPUT  FROM  it. 

The  purpose  of  a BETA  is  to  implement  the  data  flow  required  for  functional 
simulation  in  order  to  determine  the  sufficiency  of  a functional  specification. 
To  that  end,  the  fidelity  of  each  BETA  is  dependent  on  the  capabilities 
required  of  the  functional  simulator,  and  in  particular  on  the  data  contents 
determined  for  SETS. 

Generation  of  a BETA  is  more  or  less  creative  depending  on  the  fidelity 
desired.  At  the  simplest  level,  assignment  statements  may  be  employed  in 
place  of  complex  mathematical  operations.  In  TSL,  the  ALPHA:  UPDATE_STATE 
is  modeled  by  assigning  to  STATE  (a  DATA  item  ASSOCIATED  WITH  ENTITY_TYPE: 
IMAGE_IN_TRACK)  the  value  of  the  DATA  returned  by  SETS.  In  an  analytic 
model,  the  equivalent  operation  would  be  execution  of  a high-order  Kalman 
filter.  The  simple  model  is  appropriate  since  it  follows  the  logical  con- 
nectivity of  the  system  data  flow,  while  providing  a means  for  SETS  to  acti- 
vate the  required  branches  of  the  R_NETs. 
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One  of  the  ALPHAS  of  TLS  is  REDUN_DETERMI NATION.  It  embodies  the 
requirements  for  identifying  two  images  as  redundant  if  their  state  esti- 
mates are  close  enough  (relative  to  their  uncertainties)  for  them  to  be 
considered  duplicate  detections  of  the  same  object.  The  real  processing  to 
implement  such  a requirement  would  have  to  select  at  least  a subset  of  all 
images  then  being  tracked  for  state  comparison,  then  determine  redundancy 
by  an  appropriate  algorithm.  For  a functional  model,  it  is  sufficient  to 
define  the  USE  of  STATE  (a  multielement  vector  in  reality)  as  BETA  and  its 
TYPE  as  REAL.  Then  two  instances  of  IMAGE_I N_TRACK  would  be  redundant  if 
their  values  of  STATE  were  equal.  The  corresponding  SETS  activity  is 
implemented  by  having  the  DATA  returned  in  the  radar  message  selected  to 
give  the  required  probability  of  redundancy. 

3.5.2  Local  Data 

In  developing  the  BETA  for  each  ALPHA,  the  requirements  engineer  must 
also  solidify  the  attributes  related  to  DATA  flow.  As  already  noted,  some 
high-level  DATA  will  be  sufficient  for  functional  modeling,  and  will  be 
assigned  the  appropriate  TYPE  and  USE  attributes.  Similarly,  specification 
of  USE:  BOTH  for  DATA  required  in  a functional  model  at  the  same  level 
of  fidelity  as  in  an  analytic  model  will  be  accomplished.  Also,  it  will  be 
necessary  to  identify  DATA  required  for  intercommunication  of  ALPHAS  on  a 
single  R_NET  during  a single  transaction  (enablement)  of  that  net.  For 
example,  the  STATE  of  the  IMAGE_IN_TRACK  corresponding  to  the  current  return 
must  be  compared  in  REDUN_DETERMINATION  with  that  of  all  other  instances. 

Therefore,  a DATA  element  may  be  defined  as  OUTPUT  FROM  ALPHA:  UPDATE_STATE 
which  is  the  CURRENT_STATE . That  definition  is  needed  since  the  current 
instance  of  IMAC»E_IN_TRACK  (with  which  a value  of  STATE  is  associated)  changes 
during  execution  of  the  R_NET.  Therefore,  the  DATA:  CURRENT_STATE  is 
declared,  and  given  LOCALITY:  LOCAL,  TYPE:  REAL,  and  USE:  BETA.  Since 
the  value  of  the  state  vector  is  also  an  output  for  recording,  and  since  a 
MESSAGE  uses  only  LOCAL  DATA,  the  element  may  be  the  same  as  the  one  which 
MAKES  the  MESSAGE:  STATEJJPDATE  which  is  also  required  from  that  R_NET. 

RADX  procedures  (as  discussed  in  Section  3.3.6)  are  of  continuing  use 
in  analyzing  the  correctness  of  the  DATA  definitions.  This  applies  not  orly 
to  specific  software  requirements  information  but  also  to  DATA  defined  for 
simulation  purposes. 

3-68 

] 


3.5.3  SETS  Development 

SETS  is  a generic  name  assigned  to  the  driver  for  the  software  require- 
ments models.  Since  SETS  represents  the  totality  of  the  environment  to  the 
data  processor.  Its  design  and  development  should  normally  be  controlled  by 
Systems  Engineering  or  an  independent  V&V  organization.  SREM  considers  SETS 
to  be  an  input  to  requirements  development  effort  (although  in  reality  SETS 
coding  and  debug  may  be  accomplished  by  software  requirements  personnel). 

From  the  software's  viewpoint,  SETS  provides  all  stimuli  necessary 
for  each  processing  option  and  also  accepts  and  properly  executes  all  valid 
commands.  SETS  must  also  be  designed  to  properly  simulate  the  expected 
system  timeline.  Therefore,  when  an  activity  is  commanded  by  the  software 
models,  SETS  must  be  structured  to  1)  simulate  the  required  action,  2) 
calculate  how  long  the  activity  would  have  taken  in  the  real  system,  and 
3)  make  the  results  of  the  activity  available  to  the  software  at  the  proper 
simulated  time.  Close  coordination  between  the  BETA  developers  and  SETS 
designers  will  typically  be  necessary  to  ensure  that  the  response  timeline 
and  timing  interfaces  are  properly  handled. 

For  Track  Loop,  time  is  controlled  by  SETS  via  commands  from  the 
requirements  models  and  is  administered  by  the  REVS  Simulation  Executive 
using  the  Event  Calendar.  At  the  end  of  each  activity,  the  Simulation 
Executive  searches  the  Event  Calendar  and  advances  simulation  time  (RSL 
DATA  item  CLOCK_TIME)  to  the  time  of  the  next  event  to  be  processed.  When 
an  R_NET  terminates,  one  of  three  actions  may  have  occurred: 

1)  an  EVENT  was  generated  to  enable  an  R_NET  at  some  later  time, 

2)  a MESSAGE  was  PASSED  across  an  OUTPUTJNTERFACE,  or 

3)  no  future  activity  v/as  scheduled. 

Item  (1)  causes  an  entry  in  the  EVENT  calendar  indicating  the  R_NETs  future 
enablement  time.  An  R_NET  can  therefore  enable  itself  or  another  R__NET  on 
an  intermittent  or  periodic  basis.  Item  (2)  causes  execution  of  SETS  models 
and  commands  SETS  to  perform  a specific  function  at  a time  defined  in  the 
MESSAGE.  TLS  SETS  was  implemented  such  that  it  establishes  how  long  the 
commanded  action  should  take  to  perform  in  the  modeled  subsystem  and  also 
at  what  time  the  results  should  be  made  available  to  the  data  processor. 
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Because  BMD  systems  are  generally  asynchronous,  R_NEi  timing  is 
implicitly  modeled.  The  data  processing  activity  of  scheduling  actions 
of  other  subsystems  (i.e.,  Radar)  drives  the  system  sensors  much  like  an 
open  loop  servo  (i.e.,  commands  are  transmitted,  action  is  taken,  results 
are  returned).  While  SETS  is  executing  the  orders  (and  advancing  simula- 
tion time)  the  Radar  Scheduler  is  concurrently  preparing  the  next  set  of 
commands.  Since  1)  REVS  simulations  consider  requirements,  not  a specific 
architecture  and  process  design,  2)  it  is  assumed  that  the  system  imposed 
timelines  can  be  met  by  the  software,  and  3)  SETS  has  already  advanced 
simulation  time  to  the  time  of  the  next  necessary  software  activity,  simulation 
time  is  not  directly  advanced  at  the  termination  of  an  R_NET.  It  is  con- 
trolled by  the  modeling  of  the  data  processor  scheduling  of  the  timelines 
of  the  other  subsystems. 


3.5.4  Simulator  Applications 


REVS  provides  the  basic  capability  for  the  automatic  generation  of 
functional  simulations.  Also  provided  are  interface  software  for  inte- 
gration with  SETS,  various  methods  of  obtaining  data  during  simulation 
execution  and  mechanisms  to  support  post  processing  of  the  output  data. 

The  degree  to  which  these  capabilities  are  utilized  on  a program  is 
directly  dependent  on  the  objectives  of  each  particular  application. 

Track  Loop  represents  only  one  level  of  a functional  simulation.  Its 
fidelity  could  be  increased,  if  desired,  and  where  necessary  its  orientation 
or  emphasis  could  be  changed.  Track  Loop  was  developed  to  meet  certain 
objectives  which  may,  or  may  not,  exist  on  another  effort.  The  key  point 
is  that  each  application  is  different  and  engineering  judgement  must  be 
used  to  decide  what  level  of  simulator  is  needed  to  meet  the  objectives 
of  the  dynamic  validation. 
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4.0  PERFORMANCE  REQUIREMENTS 


In  the  phases  of  SREM  described  in  the  following  sections,  the  data 
processing  specified  by  the  RSL  functional  requirements  is  completed  by 
definition  of  the  necessary  performance  requirements.  These  performance 
requirements  specify  the  conditions  that  must  be  satisfied  during  real- 
time processing  in  order  for  the  system  objectives  to  be  met.  They  are 
also  statements  of  the  acceptability  criteria  that  will  be  used  for  testing 
and  validation  of  the  software  to  be  produced. 

Performance  requirements  may  be  generally  categorized  as  follows: 

a)  Accuracy  - Requirements  that  specify  the  maximum  acceptable 
software  error  in  performing  computations  or  in  making 
logical  decisions. 

b)  Range  - Requirements  that  specify  restrictions  on  the  range 
(maximum  value,  minimum  value)  of  data  generated  during 
processing. 

c)  Timing  - Requirements  that  specify  the  time  span  allowed 
for  processing,  the  times  at  which  messages  will  be  output, 
or  the  time  spacing  (frequency)  of  output  messages. 

c)  Load  - Requirements  that  specify  the  computational  load  that 
the  software  must  be  capable  of  handling,  e.g.,  "the  software 
must  provide  for  concurrent  tracking  of  300  images". 

Each  of  the  above  categories  can  be  expressed  in  RSL  to  completely  specify 
the  desired  software  subsystem  performance. 

The  approach  described  here  for  specifying  performance  requirements 
using  RSL  avoids  most  of  the  ambiguities  and  problems  of  untestability 
typical  of  specifications  written  in  free-form  English.  It  also  avoids  the 
issue  of  how  to  interpret  the  equations  which  are  frequently  Included  In 
software  specifications.  The  techniques  described  here  produce  performance 
requirements  which  are  explicitly  testable  and  unambiguous. 

The  basis  of  the  SREM  approach  is  to  unambiguously  define  the  desired 
performance  criteria  as  a precise  TEST  coded  in  the  PASCAL  language.  Each 
TEST  is  constructed  such  that  a single  pass/fail  assessment  can  be  made. 
Data  is  first  recorded  at  user  specified  VALIDATION_POINTs  and  then  pro- 
cessed by  the  executable  TEST.  The  TEST  should  be  so  designed  that  an 
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automatic  evaluation  can  indicate  success  or  failure  with  respect  to  the 
desired  performance  of  the  software. 

The  methodology  for  specifying  performance  requirements  in  RSL,  In 
the  context  of  the  previously  generated  functional  requirements,  is  described 
in  the  following  sections.  This  part  of  SREM  is  performed  in  three  phases: 

• Phase  6 - Originating  Requirement  Decomposition 

• Phase  7 - Performance  Allocation 

• Phase  8 - Analytic  Feasibility  Demonstration 

These  phases  outline  procedures  for  mapping  DPSPR  performance  require- 
ments onto  the  functional  requirements  nets,  for  allocating  accuracy,  range, 
timing  and  load  requirements,  and  for  verifying  the  completeness,  consistency, 
and  feasibility  of  the  resulting  specifications. 


4.1  PHASE  6 - ORIGINATING_REQUIREMENT  DECOMPOSITION 

4.1.1  Step  1:  ORIGINATING_REQUIREMENT  Identification 

The  first  activity  in  the  generation  of  RSL  PERFORMANCE_REQUIREMENTs 
is  to  isolate  and  identify  each  originating  (performance)  requirement  in 
the  DPSPR.  Given  a structured  and  well  written  system  specification,  this 
activity  should  be  straightforward.  Each  statement  of  performance  can  be 
transcribed  directly  into  an  RSL  ORIGINATING_REQUIREMENT  and  entered  into 

the  ASSM.  If  the  DPSPR  is  sufficiently  structured,  each  ORIGINATING REQU I RE- 

MENT  will  address  only  a single  area  of  performance  and  can  be  uniquely 
identified  using  the  appropriate  DPSPR  paragraph  number. 

In  many  cases,  this  straightforward  transcription  will  not  be  possible; 
therefore,  an  alternative  scheme  has  been  provided.  If  one  DPSPR  performance 
statement  (paragraph)  clearly  addresses  several  different  topics  then  the 
RSL  INCORPORATES  relationship  is  used  to  maintain  traceability.  This  will, 
in  effect,  generate  a hierarchy  of  ORIGINATING_RE0UIREMENTs . The  overall 
DPSPR  requirement  at  the  top  of  the  hierarchy  is  declared  in  the  ASSM,  and 
references  the  applicable  section  of  the  source  document.  Each  individual 
subtopic  is  then  declared  as  a separate  ORIGINATING_REQUIREMENT  that  is 
INCORPORATED  IN  the  top  level  requirement.  Traceability  is  thus  maintained 
through  the  levels  of  ORIGINATING_REQUIREMENTs  down  to  the  applicable 
PERFORMANCE_REQUIREMENTs.  Figure  4-1  shows  example  OR I G I N ATI NG_REQU I RE- 
MENTs  generated  from  the  TLS  DPSPR. 

4.1.2  Step  2:  Preliminary  PERFORMANCE_REQU IREMENT  Definition 

In  this  step,  the  ORIGINATING_REQUIREMENTs  identified  in  Step  1 are 
mapped  onto  the  functional  requirements  nets.  That  is,  they  are  converted 
into  the  preliminary  definition  of  TESTs  that  are  formulated  in  terms  of 
• DATA  collected  at  various  VALIDATION_POINTs  located  on  the  R_NET  and  SUBNET 
STRUCTURES.  For  each  ORIGINATING_REQU IREMENT,  the  functional  requirements 
defined  by  the  R_NET  and  SUBNET  STRUCTURES  are  examined  to  determine  those 
to  which  the  ORIGINATING  REQUIREMENT  applies.  In  some  cases  this  mapping 
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ORIGINAT  I MG— «EQ'J  I RE  ME  N t I 

TLS_DPSPR.,SFCTI0N.3_2_PERF0RmANCE.REQUIREMENTS, 

IMPLEMENTS! 

VERSION!  TLS«DPSPR, 

INCORPORATES! 

originating.requiremfnti 

TLS,OPSPR_SIJBSECTIoN_3  2 i.performance.requirehents 

ORlGINATING.REQUI»EMENTl“ 

TLS.DPSPR.SUBSECTIflN.3  2 2.PERFCRM  ancE.REQUIREMNTs 
OPIGINATING.REQUIREMENT  l” 

TLS_DPSPR-S'l8SECTIflN-3_2  3.PERFORM ancE.REQUIREMENTs 
OPIGINATING.REQUIREMENTl” 

TLS-DPSPR_SU8SECTIoK<_3_?_ate<PERPi'RMANCE_REGUIREMENTs 
ORIGINATIng^REQUIReMEkt  l“ 

TLS.DPSPP.SUdSECTIoN_3  2 5_PfcRF"RNAMCE_REQL'IREf  ENTs, 
DOCUMENTED  BYJ 

SOURCE  I TLS_DPSPR_Xi  TRaCK.LOOP  EXPERIMENT, 


ORIGINATING.REQUIREMENT! 

Tl  S.DPSPH.SUBSECT  lON-3_>2-l_PERFORMANCE-REnuiREMFNTS . 

IMPLEMENTS! 

VERSION!  TLS.DPSPR, 

DOCUMENTED  BV! 

SOURCE!  TLS„DPSPR  Xj  TRaCK.LOOP  EXPERIMENT, 
INCORPORATED  INi 

ORIGINATING.REQUIREMENTI 

TL S.DPSPR. SECT  I 0N.3.2_pErF0RmANCE„ REQUIREMENTS, 
OR  IG I NAT  ^.REQUIREMENT  I 

TLS.DPSPR.SU8SECTI0N_3<_2-2-.PeRFORMAncE_REQUIREMFnTS, 

IMPLEMENTS! 

VERSION!  TLS.DPSPR, 

DOCUMENTED  BY| 

SOURCE  I TlS„.OPSPR_X1_tRaCK„.LOOP_EXPEPIMENT  , 
INCORPORATED  I N j 

ORIGINATING.REQUIREMENT I 

TLS.DPSPR.SECT  1 0N.3. 2 PERFORMANCE. REQUIREMENTS, 


ORIGINATING.REQUIREMENT! 

TLS.DPSPR^SU8SECTl0N.3.2.3.PERF0RMANCE_REnuIRFMENTS, 

IMPLEMENTS! 

VERSION!  TLS.DPSPR, 

DOCUMENTED  BY! 

SOURCE  ! TLS.DPSPR.X1_TPACK.L0PP_EXPERIMENT , 

incorporated  IN | 

ORIGINATING.REQUIREMENT  I 

Tl S. DPSPR. SEC T I On—3.2_pErF0RMANCE. REQUIREMENTS, 

Figure  4-1  Sample  ORIGINATING_REQUIREMENTs  (Performance)  for  TLS 
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8RICINATING„REQUIREmEnTi 

TU3.pP8PR«.3UB8ECTI0N-3-,2a.«-PERF89^ANCE_REQUlREHENTS. 

IMPLEMENTS! 

VERSION!  TLS.DPSPR, 

documented  BYj 

SOURCE!  TLS.DPSPR_X1_tRaCK-,L09P.EXPERIMENT, 
INCORPORATED  I N | 

ORIGINATING.REQUIREMENTI 

TL3.0P8PR.5ECTieN.i.2.PERFflRMANCE.RE0UIREMENT8, 


ORlGINATlNG.REQUlREMENn 

TLS.DPSPR„SUBSECTI0N-3-2-5_PeRF0RMaNCE„REQUIREMEnTS, 

IMPLEMENTS! 

VfRSION|  TLS.DPSRr, 

DOCUMENTED  By  t 

SOURCE!  TlS^OPSPR^XI^tRaCK.LOOP.EXPERIMENT, 
INCORPORATED  IN  I 

ORIGINAT I NG— REQUIREMENT  I 

TLS-DPSPR_SECTION_3w2  pErFORMANCE.REQUIREMENTS, 


Figure  4-1  Sample  ORIGINATING  REQUIREMENTS  (Performance) 
for  TLS  (ContlnuedT 


4-5 


r ~~ — 


(or  decomposition)  may  be  very  simple:  the  ORI G I NAT  I NG_  REQ’J  I REMENT  may 
apply  to  a processing  function  that  is  confined  to  a single  R_NET,  and  the 
TEST  may  be  expressible  in  terms  of  existing  DATA  that  can  be  RECORDED  BY 
a single  VALIDATION_POINT  locatable  on  the  net.  For  such  cases,  the 
resultant  RSL  PERFORMANCEJEQU I REMENT  CONSTRAINS  a single  VALIDATION_PATH , 
consisting  of  a single  VALIDATION_POINT  that  RECORDS  existing  DATA  for  use 
in  the  TEST.  In  other  cases,  the  mapping  may  be  quite  complex,  e.g.,  when 
the  ORIGINATING_REQUIREMENT  effects  processing  on  several  asynchronous  nets, 
and  requires  the  modification  or  addition  of  RSL  elements  in  the  ASSM  in 
order  to  implement  the  TEST. 

Step  2 is  not  easily  configured  into  a step-by-step  methodology, 
since  many  of  the  actions  that  are  required  in  mapping  ORI G INAT I NG_REQU I RE- 
MENT s onto  the  nets  are  performed  in  parallel  rather  than  in  a stepwise, 
serial  fashion.  The  activities  to  be  performed  in  this  step  consist  of  the 
following  general  tasks. 

• Decomposition  of  ORIGINATING_REQUIREMENT$ 

• Preliminary  Definition  of  PERFORMANCE_REQU I REMENT  TESTs 

• Preliminary  Definition  of  VALIDATION_POINTs  and  VALIDATION_ 
PATHS 

These  activities  are  performed  for  each  ORI GI N ATI NG_REQU I REMENT  that 
was  identified  in  Step  1.  The  activities  are  highly  interdependent  and 
should  be  viewed  as  being  performed  concurrently.  The  functional  requirements 
defined  by  the  R_NET  and  SUBNET  STRUCTURES  are  examined  to  identify  the 
processing  that  the  ORIGINATING_REQUIREMENT  will  (or  might)  constrain,  and 
to  identify  DATA  available  on  the  nets  that  can  be  used  to  determine 
whether  the  requirement  is  satisfied.  An  attempt  is  made  to  formulate  a 
pass/fail  criterion  for  the  ORIGINATING_REQUIREMENT  in  terms  of  DATA  or 
FILEs  on  the  nets  that  can  be  recorded  at  VALIDATION_POINTs  during  pro- 
cessing. The  criterion  sought  is  one  that  can  be  incorporated  in  an  RSL 
TEST  that  explicitly  specifies  the  conditions  that  recorded  DATA  and  FILES 
must  meet.  Depending  on  the  ORIGINATING_REQUIREMENT,  attempting  to  formu- 
late the  pass/fall  criterion  may  lead  to  a decision  that: 
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• The  criterion  is  simply  stated  in  terms  of  available  DATA 

and  FILES  and  the  OR IG I NATI NG REQU I REMENT  should  therefore 

decompose  into  a single  PERFORMANCE_REQUIREMENT; 

t The  criterion  is  very  difficult  (or  impossible)  to  formulate 
in  terms  of  available  DATA  and  decomposition  of  the  ORIGINATING 
REQUIREMENT  into  seve-al  PERFORMANCE_REQUIREMENTs  is  desirable 
(or  necessary) ; 

• The  sensitivity  of  the  ORIGINATING  REQUIREMENT  constraint  to 
DATA  on  the  nets  must  be  determined  by  further  analysis  in 
order  to  formulate  the  criterion  and  to  define  the  required 
decomposi tion. 

The  activities  described  below,  supplemented  by  studies  or  simulations  as 
required,  continue  until  the  decomposition  of  the  ORIGINATING_REQUIREMENT 
into  PERFORMANCE_REQUIREMENTs  has  been  defined.  As  previously  stated,  these 
activities  are  performed  concurrently. 

4 . 1 . 2 . 1 Decomposition  of  ORIGINATING^REQUIREMENTs 

In  general,  the  DPSPR  will  establish  performance  specifications  at  a 
higher  level  than  that  of  the  SREM  functional  specifications.  Consequently, 
the  methodology  provides  for  performance  requirements  to  be  specified  as 
constraints  on  a collection  of  functional  requirements,  thereby  indirectly 
constraining  each  component  function  (R_NET,  ALPHA,  DATA,  etc.)  of  the 
collection.  This  provision  within  the  methodology  supports  design  freedom 
for  the  process  designer.  It  does  not,  however,  preclude  the  requirements 
engineer  from  "decomposing"  a DPSPR  requirement  into  component  requirements 
for  allocation  to  individual  elements  within  the  collection  of  those  R_NETs 
or  ALPHAS  to  be  constrained, should  this  be  necessary. 

When  a high-level  ORIGINATING ^REQU I REMENT  is  analyzed  during  prelimi- 

nary definition  of  its  TEST,  VALIDATION_POINTs  and  VALIDAT10N_PATHs , lower- 
level  requirements  that  it  implies  will  be  identified.  A decision  must 
then  be  made  as  to  how  the  ORIGINATING_REQUIREMENT  is  to  be  represented. 

For  example,  when  a single  ORIGINATING_REQUIREMENT  applies  to  more  than  one 
functional  requirement  defined  by  R_NETs  and  SUBNETS  that  are  not  connected 
by  EVENT  enablements,  the  ORIGINATING_REQUIREMENT  may  constrain  multiple 
VALIDATION_PATHs.  Alternatively,  a single  ORIGI NAT  I NG_REQU I REMENT  may  be 
decomposed  into  multiple  PERFORMANCE_REQUIREMENTs  which  apply  explicitly 
to  the  functional  requirements  defined  by  each  non-connective  R_NET  and 
SUBNET  STRUCTURE. 
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When  an  ORIGINATING_REQUIREMENT  is  decomposed  into  PERFORMANCE_ 
REQUIREMENTS,  these  will  each  be  TRACED  FROM  a DECISION  that  documents  the 

decomposition.  Decomposition  of  an  ORIGINATING ^REQU I REMENT  necessitates 

that  the  following  actions  be  taken  to  enter  inform,  tlon  in  the  ASSM. 

• A DECISION  that  documents  the  decomposition  via  PROBLEM, 
ALTERNATIVES  and  CHOICE  attributes  will  be  declared. 

• Each  derived  PERFORMANCE_REQUIREMENT  will  be  TRACED  FROM 
the  DECISION. 

• The  DECISION  will  be  TRACED  FR'M  the  OR I G I NAT  I NG REQU I REMENT . 

A PERFORMANCE_REQU I REMENT  imposes  a quantitative  constraint  on  the 

performance  of  certain  processing  paths.  Decomposition  of  an  ORI G I N ATI NG 

REQUIREMENT  into  a set  of  derived  PERFORMANCE_REQU I REMENT s requires  that 
the  constraint  imposed  by  the  original  requirement  be  allocated  to  those 
that  are  derived  from  it.  Clearly  the  combined  constraints  of  the  derived 
requirements  must  satisfy  the  constraint  imposed  by  the  original. 

The  allocation  process  may  require  only  a simple  mathematical  analysis 
or  it  may  require  an  in-depth  trade  study  involving  the  construction  and 
execution  of  functional  or  analytic  simulators.  If  the  allocation  is 
reasonably  simple,  it  can  be  performed  immediately  and  the  manner  in  which 
the  resultant  performance  limits  are  obtained  should  be  described  in  the 
DECISION  that  documents  the  decomposition  of  the  original  PERFORMANCE_ 
REQUIREMENT  into  the  derived  ones.  If  the  allocation  requires  that  a large 
scale  engineering  trade  study  be  performed,  then  the  conditions  and  required 
outputs  of  the  study  are  identified.  The  study  is  conducted  in  Phase  7 - 
Performance  Allocation,  described  in  the  next  section. 

If  the  PERFORMANCE_REQU IREMENT  TEST  is  completely  defined  except  for  the 
value  of  the  limit  to  be  imposed,  then  the  TEST  will  be  written  except  for 
insertion  of  the  limit,  and  VALIDATION_POINTs  and  VALIDATION_PATHs  will  be 
defined.  The  limit  for  the  TEST  will  be  inserted  in  Phase  7 at  the  completion 
of  the  allocation  study. 


: 
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4. 1.2. 2 Preliminary  Definition  of  Performance  Requirement  TESTs 


Concurrent  with  the  mapping  and  decomposition  of  the  ORIGINATING 

REQU I REMENT s and  the  identification  of  required  allocation  studies,  attention 
must  be  focused  on  a preliminary  definition  of  the  RSL  TESTs. 

The  TEST  attribute  of  a PERFORMANCE_REQU I REMENT  is  a PASCAL  procedure 
whose  purpose  is  co  explicitly  define  the  criteria  for  satisfying  the 
PERFORMANCE_REQU I REMENT.  The  TEST  is  formulated  using  DATA  and  FILES  that 
are  RECORDED  by  one  or  more  VALIDATION_POINTs  which  appear  as  nodes  on  the 
STRUCTURE  OF  VAL I DAT  1 0N_PATHs  that  are  CONSTRAINED  BY  the  PERFORMANCE_ 
REQUIREMENT.  During  a simulation,  these  DATA  and  FILES  are  recorded  in  an 
output  data  set  and  each  record  in  the  set  is  labeled  with  the  appropriate 
VALIDATION_POINT  name.  During  post-simulation  TEST  execution,  the  TEST 
accesses  desired  records  in  the  output  data  set  via  the  RETRIEVE,  SELECT, 
and  FOR  EACH  operators.  Use  of  these  operators  in  the  writing  of  a TEST  is 
described  in  the  REVS  Users  Manual.  The  same  DATA  and  FILES  may  be 
RECORDED  BY  many  VALIDATION_POINTs . To  uniquely  define  accessing  of  DATA 
and  FILES  from  the  output  data  set,  all  DATA  and  FILE  names  appearing  in 
a TEST  must  be  prefixed  with  the  name  of  the  VALIDATION_POINT  which  RECORDS 
those  instances  that  are  desired.  The  two  names  are  separated  by  a decimal 
point.  Thus,  to  refer  to  DATA  (or  FILE)  A that  is  RECORDED  BY  VALIDATION_ 
POINT  VI,  the  identifier  VI. A is  used  in  the  TEST. 

Based  on  engineering  analyses  of  the  applicable  requirements  elements 
affected  by  a DPSPR  requirement,  it  is  may  be  possible  to  1 [mediately 
define  the  precise  TEST  needed.  In  other  cases  the  form  of  the  TEST  will  be 
determined,  but  precise  definition  will  occur  in  the  Performance  Allocation 
phase.  Depending  on  the  degree  to  which  the  TEST  can  be  defined,  the 
applicable  PERFORMANCE_REQUIREMENT  can  be  entered  in  the  ASSM  with  a 
COMPLETENESS  attribute  of  'COMPLETE,  INCOMPLETE,  or  CHANGEABLE'. 

4. 1.2. 3 Definition  of  VALIDATION_POINTs  and  V AL I DAT 1 0N_P ATHs 

As  the  TEST  formulation  is  being  defined,  the  VALIDATION_POINTs  and 
VAL I DAT 1 0N_P  ATHs  with  which  information  must  be  recorded  to  support  the  TEST 
can  also  be  tentatively  defined.  The  two  operations  are  essentially 
concurrent,  since  they  each  depend  on  the  other:  there  must  be  a TEST 
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definition  in  order  to  define  the  VALIDATION_POINTs  and  VALIDATION_PATHs 
to  support  it,  but,  at  the  same  time,  the  TEST  must  be  written  in  terms  of 
information  RECORDED  BY  the  VAL I DAT 1 0N_P0 1 NTs . 

A VAL  I DAT  I ON ^PO I NT  is  analagous  to  a test  point  in  a piece  of  elec- 

tronic hardware;  it  is  a port  through  which  information  is  collected  in 
order  to  assess  performance  of  the  unit  under  test.  A single  VALIDATION_ 
POINT  may  be  used  to  collect  information  for  multiple  PERFORMANCE_REQUIRE- 
MENTs;  consequently,  it  may  appear  in  the  STRUCTURES  of  several  VALIDATION_ 
PATHs.  The  DATA  and  FILEs  declared  as  RECORDED  by  such  a VALIDATION_POINT 
will  therefore  be  the  "logical  OR"  of  those  to  be  collected  for  each  of  the 
PERFORMANCE_REQUIREMENTs  that  use  the  VALIDATION_POINT. 

The  information  RECORDED  BY  a VALIDATION_POINT  may  be  simple  DATA,  an 
entire  FILE,  DATA  or  a FILE  that  MAKES  a MESSAGE,  or  DATA  or  FILEs  ASSOCIATED 
WITH  ENTITY_CLASSes  or  ENTITYJYPEs . For  non-simple  DATA  (i.e.,  DATA  which 

are  CONTAINED  IN  a FILE,  or  are  ASSOCIATED  WITH  an  ENTITY_CLASS  or  ENTITY 

TYPE ) , care  must  be  taken  in  defining  the  instance  of  the  repeated  DATA 
to  be  RECORDED.  In  general,  the  instance  desired  will  be  selected  earlier 
on  the  net  that  contains  the  VALIDATION_POINT.  For  example,  in  Track  Loop, 
the  PULSE  which  is  relevant  for  the  PERFORMANCE_REQUIREMENT : ENERGY_PER_ 
IMAGE  is  the  one  which  was  CREATED  BY  the  ALPHA:  PICK_COMMAND.  Since  no 
intervening  activity  modifies  the  selection,  the  DATA  corresponding  to  that 
PULSE  are  available  to  the  VAL I DAT 1 0N_P0 1 NT  used  for  the  ENERGY_PER_IMAGE 
requirement.  However,  the  energy  of  that  command,  which  is  also  needed 
for  the  TEST,  is  not  so  simply  available.  The  enerqy  of  the  PULSE  is  a 
part  of  WF_CHARACTERISTICS  in  the  FILE:  WAVEFORM_TABLE . The  link  between 
a PULSE  and  the  WAVEFORM_TABLE  is  established  by  correlation  of  the  type 
of  transmission,  identified  in  PULSE__TYPE  (and  also  RADAR_TYPE)  and  in  WF_ 
NAME.  There  are  several  ways  of  obtaining  the  required  information.  An 
example  method  is: 

1)  Record  either  the  PULSE_TYPE  or  the  RADAR_TYPE  from 
XMIT_R; 

2)  Add  a VALIDATION^  I NT:  STARTING_POINT  following  the  ALPHA: 
STARTER  to  RECORD  the  FILE:  WAVEFORMJABLE ; 

3)  In  the  TEST,  correlate  the  RECORDED  information  to  obtain 
the  energy  of  the  PULSE  from  the  WAVEFORM_TABLE . 
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The  RSL  associated  with  this  example  is  shown  as  part  of  Figure  4-2  at  the 
end  of  this  section. 


1 


The  correct  placement  of  VALIDATION^POINTs  requires  careful  inter- 
pretation of  the  DPSPR  specification  to  ensure  that  the  intent  of  the 
specification  is  preserved.  If  the  exact  intent  of  an  OR  IGI  NAT  INfl_REQU  I RE  - 
MENT  contained  in  the  DPSPR  is  ambiguous  or  unclear,  then  clarification 
should  be  sought  from  the  systems  engineering  organization.  If  clarifi- 
cation cannot  be  obtained,  then  a DECISION  that  documents  the  PROBLEM,  the 
various  ALTERNATIVES  and  the  CHOICE,  should  be  entered  in  the  ASSM.  The 
DECISION  is  then  TRACED  from  the  ambiquous  ORIOINATINC,_REQUIREMENT. 

As  an  example,  consider  the  specification  statement  in  the  TSL  DPSPR 
(Appendix  A)  which  requires  that  "The  DPS  shall  allocate  radar  commands  so 
that  not  more  than  (TBD)  joules  are  commanded  per  image,  . . .."  This 
apparently  explicit  requirement  has  at  least  three  interpretations  that 
require  different  placement  of  the  VALIDATION_POINT. 

1)  The  allocator  shall  assign  track  rates  such  that  the 
accumulated  sum  of  the  energy  for  each  image  over  the 
engagement  (the  product  of  the  allocated  pulse  rate, 
the  energy  per  pulse  and  the  duration  of  the  allocation) 
shall  not  exceed  the  specified  limits; 

2)  The  energy  required  by  the  radar  commands  transmitted  across 
the  interface  to  the  radar  shall  not  exceed  the  specified 
limit;  or 

3)  The  energy  required  by  the  radar  commands  acted  upon  by  the 
radar,  as  detected  by  the  DPS  in  the  radar 

return  messages,  shall  not  exceed  the  specified  limit. 

Since  not  all  of  the  pulses  allocated  per  image  may  be  scheduled  and 
since  some  of  the  scheduled  pulses  may  be  preempted  by  the  radar,  the 
three  interpretations  lead  to  different  performance  requirement  definitions. 
For  the  first  interpretation,  the  VALIDATION_POINT  should  be  located  at  the 
output  of  the  allocator;  for  the  second  interpretation,  the  VALIDATION_POINT 
should  be  located  at  the  input  to  the  OUTPUT__INTERFACE : RADAR_0UT;  for  the 
third  interpretation,  the  VALIDATION_POINT  should  be  located  at  the  output 

of  the  INPUT INTERFACE : RADAR_IN.  In  the  Track  Loop  example,  development 

of  the  PERFORMANCE_REQUIREMENT  was  based  on  the  second  interpretat  on  and 
is  TRACED  FROM  a DECISION  which  delineated  the  development  process,  through 


4-11 


use  of  the  DECISION  attributes,  the  PROBLEM,  the  ALTERNATIVES  and  the 
CHOICE.  The  RSL  associated  with  this  example  is  shown  in  Figure  4-2. 

Identification  of  a specific  TEST  for  a PERFORMANCE_REQU IREMENT  may 
require  DATA  that  has  not  been  defined  in  the  functional  requirement 
description  of  the  DP  subsystem.  Also,  it  may  be  inconvenient  to  collect 
and  correlate  data  from  two  VALIDATION__POINTs  appearing  on  disjoint  paths 
or  net  structures.  Therefore,  the  requirements  engineer  may  define  DATA 
elements,  ALPHA  elements  and,  in  some  cases,  R_NET  or  SUBNET  STRUCTURES 
with  attributes  ARTIFICIALITY:  VALIDATION  to  convey  the  needed  DATA  to  a 
VALIDATION_POINT  where  it  may  be  recorded  for  a TEST.  For  example,  in 
Track  Loop,  suppose  that  a performance  constraint  establishes  a maximum 
delay  time  between  the  arrival  of  a track  return  message  at  the  INPUT_ 
INTERFACE  RADAR_IN  and  the  time  at  which  the  data  contained  in  the  return 
message  is  incorporated  in  the  data  which  makes  the  command  message  that 
passes  to  the  radar  through  the  OUTPUT_INTERFACE  RADAR_0UT.  The  connection 
between  the  two  interfaces  is  asynchronous  due  to  scheduling  operations  and 
use  of  the  ENTITY_TYPE:  IMAGE_IN_TRACK  in  R_NET:  SKED_R.  Since  no  one-to-one 
correlation  exists  between  the  return  received  and  the  command  issued,  a 
validation  DATA  item,  RETURN_TIME,  can  be  defined  and  ASSOCIATED  WITH  the 
ENTITY_TYPE:  IMAGE _IN_TRACK.  This  DATA  item  would  be  OUTPUT  FROM  the  UPDATE_ 
STATE  ALPHA,  where  it  would  be  set  equal  to  the  current  value  of  engagement 
time,  and  would  be  RECORDED  BY  a VAl.IDATION_POINT  located  on  the  the  R_NET 
XMIT_R  immediately  preceding  the  OUTPUT_INTERFACE  RADARJDUT. 

Information  conveyed  by  an  element  type  with  ARTIFICIALITY: 

VALIDATION  must  be  provided  in  the  real-time  process  when  it  is  being  used 
to  validate  the  process  design  against  the  system  performance  specification. 
In  practice,  element  types  so  defined  represent  a counterpart  to  the  hard- 
ware test  point  and,  like  their  equivalent,  may  be  retained  in  the  fielded 
system  by  management  directive. 


4-12 


OP IG I N A T ikG.HEQUIREMENT  : 

TLS.DPSPR.PARAGRAPH^J.^.U.B.PtRF  ARm  A NCE.RF  OU I R£  »l  N T S , 
DESCRIPTION! 

"OPSPP  PARAGRAPH  1.2.UCR),  RESOURCE  CONTROL,  STATES  THAT 
('THE  DPS  SHALL  ALLOCATt  PaDaR  COMMANDS  S*  T h A T NAT  mArF. 
THAN  (TdO)  JOULES  ARE  COMMANDED  pER  J"AGF , Nf'F  HARE  Than 
C T bO ) KILAHATTS  AR  (TflD)  PuLSf  S/SECDND  f H-L  IMAGES  IN 
TRACK,  ' 

TRACES  TAj 

DE  C I SI  AN  j RAQaR_PeSpUoCF_CAnTRol_hi 


DECISIan j RAD  A R_RE  SOURCE.,  C AnT»«L-B  1 . 

ALTERNATIVES! 

"It  THF  ali  Ac  a T PR  Shall  asSjC-n  track  ratfs  S«  :c  m Thai  jnt 
cumulative  sum  af  thf  Energy  for  each  image  avek  Twt 

ENGAGEMENT  (The  PRA0IICT  tF  ALLOCATED  PULSE  RATE, 

ENERGY  DE  R PULSE*  AND  DyRATT^M  OF  AL(ACATIAn)  SHALL 
NAT  EXCEED  (TBD)  JAULES, 

2,  ThF  ENERGY  REQUIRED  PY  THE  «A[.A»  CA'<maM)S  TRANSMITTED 
ACRASS  The  INTERFACE  Tp  Thf  radar  Shall  nat  I XlEED 
(TED)  JAULES, 

i,  The  ENFRGy  REQUIRED  By  thf  radar  commands  acT[D  UP An 
By  THE  RA0AP  AS  DETECTED  r'Y  The  dps  tn  THE  return 
MESSAGES,  shall  NAT  EXCEED  (Tpl)J  JAULES.". 

CHP ICE  ! 

"2,  THE  ENERGY  REQUIRED  «y  THE  DApAR  COMMANDS  T r A f $ m I T T E T 

across  the  interface  to  thf  radap  shall  rat  exceed 

(THD)  Joules  SHALL  BE  TeSTFD  f Ah  COMPLIANCE  At  ThE 
INPUT  TA  THF  OUTPUT  INTERFACE:  hadap_m  t . " , 

PROBLEM! 

"OPSPR  PARAGRAPH  J,2,«l(ftJ,  sTATEMfNT  (’The  DPS  SHALL 
ALLOCATE  RADAR  COMMANDS  SO  that  naT  MORE  than  Ct«D)  JAULES 
ARE  COMMANDED  PER  IMAGE,,.. •)  ai.LA*S  F"R  THprc  POSSIBLE 

Interpretations  in  determining  the  paint  ai  -high  t^e 
FEPFARmanCF. REQUIREMENT  TEST  IS  ApPLlED.", 

TRACES  TAj 

PFRFORMANr.E_REQUIREHENT  I E M'EPGv_riR_1  mAgF 

VALIDATI  AN.PA  Th  : R A ()  A R—C  OMR  ANi)_(H'  Tf’ilT 

VAL  ID  AT  IAnIf  A I NT  ! R-  ADAR^C  AMMAND_,-HTPUT„f  AINT  , 

TRACFl)  FROM! 

OPIGINAT  ING.RECJUIREMFNT  ! 

TL  S.DPSPR.PiWAGRAPH. X ?_u.B-PF RF A nCe_R F UU I RtR E N T S , 


Figure  4-2  RSL  Representation  of  Performance  Requirements 
at  End  of  Phase  6 (TSL  Example) 
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PERFORMANCE  *EOIilRF‘T*;Tl  Energy  RfR  1 m A G F , 

Tf  ST  t 
"const 

ENrRGY_CIf,IT  = b.O;  (*  T^  Pflci^Y  RfPL  ACt  MR  >JT  fliR  (Tm>),  *1 

V A R 

iMAGE.ENf RGY  ! REAl» 

BEGIN 

ENE  RGY-PER-ImAGE  J sTKIlf  J 

RETRIEVE  Ei«ST  RECORDING  FOR  starting-point ; 

FOR  EACH  C?-lMAGE_hAMpPvF P RECORDING 
CO 

I H A G£_ F MERG Y l s n • 0 ; 

FOR  EACH  R ADAR-C^INAF  D- «L  TpUT-PIJT  NT  k f,  C.  0 R P I n G 

S'JCH  that  (R AqaR-cOmm anp-OUTP' 'T_PP InT , T ARGE T-iT s 
C2„I*A(,E_H4KpOvER,Mr*_Tni 

IP 

SELECT  FIRST  RECORD  from  ST  AR  T I Nf.-P'J  I N T . * A Vt  F CRM-  T 4BLE 
SUCH  THAT  (rAL)AR-COmm  AMp^OUTt'l  T-Pfll.jT  ,RAUAR-T  YPE  = 
STARtInG-PoInT ,hE_n A Hf  ) ; 

TF  RECORD— F (JUNO  T Hf~ 

I h aGL— ENERGY  j s im aDF-Et £RGy* 

ST  ARTlNG-F'PTNT  ,wF-C^ARACTERISTiCS> 

f npforfachi 

IF  ( lMAGE-ENFRGY>ENEt,GY_l  IMI  T ) Tm£> 

Enfrgy^peR^Ihagf : =f  a~se  > 

ENTFOREACH 

end; 

CONSTRAINS! 

valIDaTION-PaTh;  c^-.h  a*  p p vfr_c  n k'«  ANQ-iNpijT 

V A L I 0 A T I ON-P  4 TH  r R A p A B_  C ON*  AnP_Mi  T PU  T 
VAlIPATION-P ATh j rAPabI-AvEF  «pM_PBfpr R T I E s • 

traced  from; 

DFCISIPNS  RAUAR-PfS',,tiRC[.Cf,NTRi»L-P1 
OP  IGI  NAT  ING.RE  JlilRfF  [ NT  5 

US-PPSPR-PARAGRADH_  1_?-U_p_PF  RFPRwAr.rE_PF.UUlRtHENTS, 


yALlDATlOFi.RATHj  C ?„w  4 N'QO  V f R_  C 0 mm  a NP_  I NPl  i T , 

REFERS  TP j 

VAL  I OAT  TPN-PO  PvT  ; CP-  rM  AGE-HA  Nf»ovF  R. 

CONSTRAINED  hyi” 

PERFORMANCE^ REQUIREMENT!  E Ml  RGV-PF.  R-I  m a gE  , 
traced  from; 

ORIGINATING^ REQUIRE M'F  NT  I 

TlS-DPSPR-RAR4GWAPh-S^  ?-«— P— PERFORM  4 NrE-(.fuU  I REMfcMS, 
PATH  I 

VALIDATION— POINT : C2— I H A Gf .HANDOVER 

END. 

Figure  4-2  RSI  Representation  of  Performance  Requirements 
at  End  of  Phase  6 (TSL  Example)  (Continued) 


4-14 


VALIDATION- PATh:  RADAW-CP^ANr  f»LTpUT, 

REFERS  TO: 

VALIDATJfl  N_P  0 I M T ; RADAR  CO^MA  U^^LITPHT-POINT. 

constrained  flv:" 

PEHFPRHanCE«.»EDUIRemT-M  I E^ERRv^PER-ImA&E 
PERFPRMAnCE.REqUIRe^ENT:  • PULSES_pFR_SECONi; 

performa n ce_ RE q dire tent:  r ao  I a t £ D— PO  "E  R • 

TRACFO  from: 

DF CIS  I ON:  RA0  4R-ReS«URCe_C',nTROL-H1 
DECISION:  RAt)AR-RESflufiCE-C0NTRfiL.P2 

ORIGINATING-REOUIRePEnT  : 

TLS_DPSPR-PARAGRAPH-i_?_u_P-PFRFnRMAh4CE-REUUlRLPENTS, 

PA  Th  : 

VALIDAT  ION-POI  IT  • RaCAR  CPIMMAND-OUTPIJT-POINT 
ENC, 


VALIDATION-PATH:  RADAR-WAvEfORP  PROPERTIES. 

REFERS  T o j 

VALIDAT I ON-POINT:  START  I NG— po I NT  * 

constrained  ry: 

PE  RF0RMANCE_Rf:DUIREPt:NT:  E N£ RG v_PEP_I M AGE 
PERFORM amCE.REQU I RfPFNT:  R ad  I a tED-p”“E R . 

TRACED  From: 

ORIGINATING— WEDUIrETENT: 

Tl  S-DpSPR-P  A RAGP  A Ph-  5_?_«_H_PFRF  OPM  A nC  E-h  EG  LI  I RE  P t N T S , 
PATH  5 

V A L T D A T I 0 N„P  OlNT:  S T A R T I N G-P  0 I N T 
END. 


VAl IDAT ION— POINT : C 2- 1 ‘•’AGE _h and OVEp. 

records: 

DATAj  HO— I D , 
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Figure  4-2  RSL  Representation  of  Performance  Requirements 
at  End  of  Phase  6 (TSL  Example)  (Continued) 
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Figure  4-2  RSI  Representation  of  Performance  Requirements 
at  End  of  Phase  6 (TSL  Example)  (Continued) 
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4.2  PHASE  7 - PERFORMANCE  ALLOCATION 


In  Phase  6,  performance  requirements  in  the  DPSPR  were  correlated  with 
the  software  function  requirements  expressed  by  the  R_NETs  and  SUBNETS.  Based 
on  the  analyses  performed,  those  DPSPR  performance  requirements  which  were  not 
directly  mappable  onto  the  NETS  were  decomposed  into  a set  of  PERFORMANCE_ 
REQUIREMENTS.  The  analyses  upon  which  these  decompositions  were  based  varied  in 
the  level  of  detail  considered,  depending  on  the  nature  of  the  particular 
decomposition.  Generally,  however,  they  were  on  a functional  rather  than 
an  analytic  level.  They  were  sufficient  to  determine  the  functional 
relationships  between  a DPSPR  parameter  to  be  constrained  and  the  pro- 
cessing described  by  the  R_NETs,  i.e.,  they  were  sufficient  for  OR I G I NAT I NG 

REQU I REMENT  decomposition.  In  many  cases,  the  analyses  performed  in  Phase 
6 were  also  sufficient  to  serve  as  the  basis  for  allocation  of  performance 
limits  to  the  PERFORMANCE_REQUIREMENTs  derived  from  the  decomposition.  In 
some  cases,  however,  the  decomposition  analyses  must  be  supplemented  with 
more  in-depth  studies  in  order  to  allocate  these  limits. 

The  purposes  of  the  allocation  studies  performed  in  Phase  7 are: 

1)  To  define  performance  limits  to  be  incorporated  in 
PERFORMANCE_REQUIREMENT  TESTs, 

2)  To  verify  the  decomposition  analyses  performed  in  Phase  6, 
and 

3)  If  a TEST  involves  the  use  of  a reference  algorithm  as  a 
comparison  standard  for  the  software  design,  to  define 
that  algorithm. 

The  allocation  studies  determine  the  sensitivity  of  the  originating 
DPSPR  requirement  to  performance  variations  in  the  various  functional  areas 
affected.  This  is  necessary  in  order  to  evaluate  tradeoffs  between  the 
derived  requirements  and  in  order  to  select  an  allocation  which  is  not 
overly  restrictive  in  any  particular  dimension.  It  is  desirable  to  use 
the  least  constraining  set  of  PERFORMANCE_REQUIREMENTs  that  will  guarantee 
satisfaction  of  the  DPSPR  requirement. 

The  allocation  studies  may  cover  a complete  range  of  engineering  analy- 
ses and  techniques  (i.e.,  they  may  consist  of  a manual  mathematical  analysis, 
they  may  require  analysis  support  from  functional  simulations,  or  they  may 
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require  the  construction  of  detailed  models  for  an  analytic  simulation). 
Recall  that  a functional  simulation  has  previously  been  generated  from  the 
functional  specification  using  the  SIMGEN  function  of  REVS,  and  is  readily 
available  to  support  these  analyses.  If  analytic  models  are  constructed, 
these  may  later  be  used  as  GAMMA  models  for  the  Analytic  Feasibility 
Demonstration  (Phase  8),  or  may  be  incorporated  in  a TEST  as  a reference 
algorithm  against  which  the  performance  of  the  software  design  may  be 
assessed. 

The  allocation  approach  should  be  evaluated  by  a formal  design  review 
for  invalid  assumptions,  inadvertent  overconstraints,  etc.  This  review  is 
assisted  by  the  capability  of  RADX  to  extract  the  traceability  of  the 
decomposition  DECISIONS  to  the  ORIGINATING_REQUIREMENTs , to  the  functional 
elements  (R_NETs,  ALPHAS,  etc.),  and  to  other  DECISIONS.  The  adequacy  of 
the  projected  performance  models  should  also  be  reviewed  to  assure  that 
all  measures  of  performance  have  been  accounted  for.  This  should  be  a 
technical  review  conducted  much  like  the  preliminary  design  review  for  a 
software  design. 

The  results  of  the  allocation  studies  may  lead  to  revision  of  the 
requirement  decomposition  that  was  performed  in  Phase  6.  If  so,  then 
the  decomposition  DECISION  that  was  declared,  and  the  associated 
PERFORMANCE_REQUIREMENTs , VALIDATION_POINTs , and  VALIDATION_PATHs  that  it 
TRACES  TO,  must  be  replaced  or  revised  to  reflect  the  new  decomposition. 

As  each  allocation  study  is  completed,  the  results  of  the  study  are 
used  to  complete  the  TEST  attributes  of  the  PE"rORMANCE_REQUIREMENTs  that 
were  analyzed.  Study  results  are  documented  either  directly  in  the 
decomposition  DECISION  or  in  a technical  report  which  is  declared  in  the 
ASSM  to  be  a SOURCE  which  DOCUMENTS  the  DECISION. 

After  the  allocation  process  is  completed  and  the  ASSM  is  updated, 
the  RADX  function  of  REVS  is  used  to  verify  that  the  content  of  the  ASSM 
is  complete  and  consistent.  When  completeness  and  consistency  are  verified, 
the  PPR  is  prepared  using  RADX  to  extract  information  from  the  ASSM  and  to 
list  it  in  the  format  that  has  been  selected  by  project  management.  At 
this  point,  the  steps  of  the  methodology  for  developing  performance  require- 
ments have  been  completed.  The  ASSM  data  base  has  been  built  with  liberal 
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use  of  the  TRANSLATOR  and  RADX  segments  of  REVS  to  ensure  the  accuracy  and 
completeness  of  each  PERFORMANCE_REQUIREMENT  description.  An  analytic 
simulator  can  now  be  constructed  to  demonstrate  the  feasibility  of  a 
mathematical  solution  to  the  software  requirements  as  stated  in  the  PPR. 
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4.3  PHASE  8 - ANALYTIC  FEASIBILITY  DEMONSTRATION 


k 


At  this  point  in  SREM,  a complete  set  of  functional  and  performance 
requirements  have  been  developed  for  the  DPS  and  documented  in  the  Process 
Performance  Requirements  specification.  The  PPR  contains  sufficient  in- 
formation for  the  process  designer  to  design,  implement  and  test  the  end 
product  software.  There  is  one  major  issue,  however,  that  has  not  yet 
been  resolved;  that  is,  can  an  engineering  solution  be  developed  that  will 
meet  the  PPR? 

This  phase  of  SREM  provides  for  the  demonstration  of  data  processing 
subsystem  analytic  feasibility  as  a part  of  the  overall  requirements  vali- 
dation activity.  The  demonstration  involves  the  design,  implementation, 
integration,  and  test  of  a candidate  design  (including  analytic  algorithms 
or  GAMMAs)  which  meets  all  the  requirements  described  in  the  PPR  except  for 
those  associated  with  timinq.  The  objective  of  the  feasibility  demon- 
stration is  to  1)  provide  a "breadboard"  design  under  the  same  logical 
requirements  as  the  real-time  process,  2)  test  this  candidate  design  in  a 
simulated  environment,  3)  evaluate  the  performance  of  the  candidate  pro- 
cess against  the  specified  validation  criteria,  and  thus  4)  increase  con- 
fidence in  the  feasibility  of  the  PPR  requirements  by  illustrating  a single- 
point solution  for  the  requirements  specified.  In  areas  where  candidate 
GAMMAs  cannot  be  developed,  the  corresponding  requirement  is  potentially 
infeasible,  thus  identifying  a problem  area  to  be  addressed  at  the  system/ 
subsystem  requirements  level.  In  addition  to  the  establishment  of  analytic 
feasibility  of  the  requirements,  the  candidate  design  can  also  be  used 
directly  as  a design  and  validation  tool  by  the  process  designers  and  the 
V&V  organization.  The  GAMMA  models,  since  they  are  guaranteed  to  effect 
the  required  transformations  (input  to  output),  can  be  augmented  with 
execution-time  models  and  used  as  initial  models  for  the  real-time  process 
design. 


4.3.1  Form  of  Feasibility  Demonstration 


The  algorithms  associated  with  the  feasibility  demonstration  are 
developed  and  integrated  into  a candidate  design  which  meets  all  require- 
ments of  the  PPR  (exclusive  of  timing  requirements).  The  candidate  design 
is  in  the  form  of  an  analytic  non-real -time  simulation,  or  emulation, 
which  is  exercised  against  a System  Environment  and  Threat  Simulation 
(SETS  or  similar  subsystem  models)  simulating  the  threat,  the  system 
environment,  and  non-data-processing  subsystems.  The  emulation  should 
contain  all  of  the  validation  points  specified  in  the  PPR;  thus  data  is 
collected  and  performance  evaluated  under  the  same  criteria  as  the  real- 
time process.  Further,  the  SREM  SETS  models  can  be  constructed  almost 
identically  to  the  driver  used  to  validate  the  real-time  process  and  thus 
establish  a common  performance  evaluation  data  base.  Results  of  formal 
testing  of  the  candidate  design  against  a predetermined  set  of  test 
scenarios  can  be  documented  along  with  any  applicable  unit  tests  that  were 
conducted  for  individual  algorithm  validation. 

4.3.2  GAMMA  Development 

Each  candidate  algorithm  will  generally  be  developed  by  an  expert  in 
the  appropriate  engineering  or  technology  field.  The  design  activity  uses 
the  descriptions  of  the  RSL  requirements  to  define  what  function  each 
algorithm  must  accomplish,  how  well  the  function  must  be  performed,  and 
what  information  should  be  accepted  as  inputs  and  produced  as  outputs. 
Mathematical  specifications  of  the  algorithms  are  then  implemented  within 
the  structure  of  the  R_NETs  as  executable  GAMMAs. 

The  PPR  DATA  items  will  usually  be  defined  at  a higher  level  than 
will  be  needed  to  build  an  excutable  analytic  simulation.  In  general, 
very  few  DATA  with  USE  = GAMMA  will,  at  this  point,  exist  in  the  ASSM. 

The  lower  level  data  items  must  be  defined  and  entered  in  the  ASSM  as 
either  independent  new  elements  or  be  INCLUDED  in  the  appropriate  higher 
level  DATA.  RADX  can  be  used  to  verify  the  correctness  of  the  new  entries 
with  respect  to  USE,  TYPE,  and  LOCALITY. 

After  the  algorithm  (and  data  derivations)  have  been  completed  the 
mathematical  relationships  are  implemented  as  executable  GAMMAs  in  the  PASCAL 
language.  The  executable  descriptions  look  like  PASCAL  procedures  with 
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omission  of  the  procedure  header  and  with  augmenting  statements  for  that 
part  of  the  reguirement  representing  access  to  data.  All  of  the  normal 
PASCAL  programming  features  and  facilities  are  available,  except  that  all 
data  that  is  not  strictly  local  to  a BETA  or  GAMMA  must  be  explicitly 
declared  in  the  ASSM.  The  REVS  Simulation  Generator  processes  these  execu- 
table descriptions  to  produce  standard  PASCAL  procedures  for  incorporation 
into  the  GAMMA  level  simulation.  This  is  discussed  in  detail  in  the  REVS 
Users  Manual . 

4.3.3  Benefits  Derived 

The  explicitness,  completeness,  and  testability  of  the  software 
reguirements  are  enhanced  by  the  process  of  constructing  a candidate  solution. 
If  additional  assumptions  or  information  about  the  system  are  reguired  to 
accomplish  the  candidate  design,  these  assumptions  will  be  explicitly 
added  to  the  reguirements  specification.  This  type  of  validation  aids  in 
determining  the  oversights  in  the  requirements  and  system  engineering. 

An  extremely  important  goal  satisfied  by  the  development  of  a feasibi- 
lity demonstration  is  the  establishment  that  the  software  requirements  are 
actually  testable.  Since  the  candidate  design  applies  the  PERFORMANCE_ 
REQUIREMENT  TEST  criteria  in  the  same  manner  as  the  real-time  process,  the 
performance  evaluation  associated  with  the  candidate  design  will  necessarily 
isolate  any  requirements  which  cannot  be  tested.  If  a requirement  is  found 
to  be  untestable  or  unverifiable  through  the  testing  of  the  candidate 
process,  the  particular  requirement  will  be  changed  to  a testable  criterion. 

The  development  of  an  analytic  point  solution  via  a candidate  design 
establishes  the  feasibility  of  the  requirements  criteria.  This  existence 
proof  assures  the  process  designer  that  there  is  at  least  one  set  of 
algorithms  that  satisfies  the  specified  logical  and  computational  require- 
ments. The  process  designer  is  free  to  apply  these  candidate  algorithms  as 
appropriate  to  solution  of  the  real-time  process  design  problem. 
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PART  II  - MANAGEMENT  APPROACH 


5.0  INTRODUCTION 

One  of  the  major  benefits  in  using  the  SREM  tools  and  techniques  to 
develop  software  requirements  is  that  the  process  is  inherently  manageable. 
The  technical  approach  consists  of  specific  activities  which  have  well 
defined  beginning  and  ending  points.  Also  the  degree  of  automation  pro- 
vided by  REVS  allows  a high  level  of  management  visibility  which  is  ordi- 
narily not  attainable  in  the  specification  development  process. 

The  three  sections  which  follow  discuss  the  more  important  aspects 
of  managing  software  requirements  engineering: 

• Defining  Measurable  Milestones 

• Cost  and  Schedule 

• Management  Control. 

The  emphasis  in  these  sections  is  to  describe  the  management  considera- 
tions which  are  unique  to  the  application  of  SREM.  Just  as  Part  I will  not 
make  good  requirements  engineers  out  of  technicians,  Part  II  will  not  make 
good  managers  out  of  clerks.  Even  good  managers,  however,  can  be  relatively 
ineffective  if  they  do  not  have  the  means  to  establish  visibility  and  con- 
trol. Part  II  is  intended  to  give  the  experienced  manager  an  understanding 
of  how  the  tools  and  techniques  of  SREM  can  be  used  to  establish  and  main- 
tain a sound  management  plan  for  the  specification  of  software  requirements. 
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6.0  DEFINING  MEASURABLE  MILESTONES 

The  key  to  successful  management  of  software  requirements  engineering 
is  the  establishment  of  meaningful,  clear,  and  measurable  milestones.  There 
is  a tendency  to  treat  requirements  generation  as  a level  of  effort  problem 
since  the  job  of  milestone  definition  is  somewhat  nebulous  and  imprecise 
using  conventional  approaches.  Establishing  milestones  such  as  "Processing 
Performance  Specification  - First  Draft",  Processing  Performance  Specifica- 
tion - Second  Draft",  etc.,  may  provide  clarity  and  superficial  measurability 
but  does  not  establish  a meaningful  or  effective  management  tool. 

Management  of  an  activity  using  the  Software  Requirements  Engineering 
Methodology  (SREM)  can  be  extremely  effective  because  the  discipline  in- 
herent in  SREM  permits  segmenting  the  effort  into  activities  which  have 
meaningful  and  measurable  terminations. 

As  an  example,  consider  the  SREM  procedures  for  generation  of  func- 
tional software  requirements.  An  overview  of  the  applicable  SREM  phases  is 
shown  in  Figure  6.1.  The  initial  activity  is  a preliminary  evaluation  and 
organization  of  the  source  specifications.  This  is  accomplished  by  an 
initial  definition  of  the  R_NETs.  Once  this  activity  is  complete,  parallel 
development  of  the  segmented  requirements  can  proceed.  As  the  requirements 
segments  are  developed,  they  are  entered  into  the  REVS  data  base  (ASSM)  for 
static  evaluation.  When  the  ASSM  entry  for  all  software  requirements  is  J 

complete,  a functional  simulation  is  generated  and  a dynamic  evaluation 
performed  to  complete  the  functional  requirements  validation.  At  various 
points  in  this  process,  problems  in  the  source  specifications  are  identified 
and  fed  back  to  the  systems  engineer. 

Each  of  these  five  phases  ends  with  the  development  of  an  intermediate 
product  and  thereby  constitutes  an  initial  set  of  high  level  milestones. 

As  was  shown  earlier,  the  status  of  these  intermediate  products  can  be 
automatically  assessed  in  many  areas  using  the  support  features  of  REVS. 

Given  that  the  completion  of  each  SREM  phase  represents  a significant 
milestone  within  itself,  a much  finer  decomposition  is  necessary  to  effec- 
tively manage  and  control  the  sub-elements  of  the  requirements  development 
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process.  To  accomplish  this, each  SREM  phase  can  be  broken  down  into  a 
definitive  set  of  milestones  via  a two-step  process.  First,  the  specific 
technical  activities  necessary  to  develop  the  desired  product  are  identified. 
Then  the  key  review  and  control  points  peculiar  to  the  specific  program 
are  defined  and  integrated  with  the  technical  milestones.  An  example  of 
this  process  for  Phase  I is  described  i n the  following  sections. 

6.1  TECHNICAL  MILESTONES 

A sample  set  of  technical  milestones  is  shown  in  Figure  6-2  for  Phase 
I,  Definition  of  Subsystem  Elements.  Each  of  the  milestones  was  derived 
directly  from  the  discussion  of  Phase  I activities  given  in  Section  3.1. 

Eight  milestones  have  been  identified  in  this  sample;  for  different  appli- 
cations these  could  be  added  to,  or  modified,  to  emphasize  specific  pro- 
grammatic objectives. 

The  beginning  point  for  the  overall  software  requirements  development 
process  is  the  baselining  of  the  system  level  source  specification  by  the 
Configuration  Control  Board  (CCB).  Once  this  is  accompl ished, technical 
activities  are  focused  on  clearly  specifying  the  direct  interactions  of 
the  software  subsystem  with  its  external  environment.  Three  milestones 
were  specified  for  completion  of  the  RSL  INTERFACE  and  MESSAGE  definition 
and  the  necessary  supporting  data  hierarchy. 

One  milestone  is  provided  for  the  completion  of  each  R_NET  to  the 
ALPHA  level.  Since  the  number  of  R NETs  is  driven  by  the  necessity  to 
accept  or  produce  data  at  the  subsystem  interfaces  (which  were  defined 
at  milestone  1.1),  the  required  number  of  nets  can  be  determined  early 
in  the  planning  process.  The  final  four  milestones  in  the  example  are 
directed  to  completion  of  the  requirements  information/data  structures 
and  documentation  of  all  engineering  decisions  that  were  made  during  the 
activity. 

Figure  6-2  does  not  represent  a series  of  technical  activities  in 
which  the  predecessor  must  be  fully  completed  before  the  next  effort  can  be 
initiated.  In  most  cases  overlap  of  the  activities  would  be  scheduled 
as  soon  as  possible.  For  example,  after  each  individual  INTERFACE  is 
defined,  then  the  work  can  proceed  on  formalizing  the  precise  content  of 
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PROBl EM ! 

"TRACKING  CAN  BE  EXPRESSED  AS 

Synchronous  or  asynchronous.". 

TRACES  TO! 

ALpHA!  P TCK..C  ANDlf)  a TF  S , 

TRACED  FROM! 

OB  IG  I N A T I NG.RFUU  I WeM  F T ! 

FL  S_DPSDR_PARAGRApH_  i_  3_A_E  UNO  T I "f  At  _F(  DuIRE  M Ms. 


Figure  6-4  Sample  Decisions  from  Track  Loop 
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not  the  software  requirements  adequately  reflect  the  intent  of  the  source 
specifications  and  to  what  extent  the  software  requirements  provide  an 
appropriate  base  for  process  design.  The  former  issue  can  be  resolved  by 
analyzing  the  DECISIONS  against  the  source  specification.  These  can  be 
categorized  into  those  with  major  effect  on  software  requirements  and 
those  with  minor  effect  on  the  software  requirements.  Baselining  may  be 
deferred  until  certain  major  problems  are  resolved  and  the  number  of  minor 
problems  is  reduced  to  an  acceptable  level.  The  visible  act  of  deferring 
a major  milestone  can  bring  considerable  pressure  to  work  problems 
expeditiously. 

6.3  SUMMARY 

The  preceding  was  an  example  of  how  the  SREM  activities  described  in 
Section  3.1  can  be  related  to  measurable  and  meaningful  milestones.  An 
identical  approach  can  be  used  for  the  activities  described  for  the  other 
phases  of  SREM.  The  activity  networks  presented  are  not  intended  to  be  a 
universal  SREM  management  plan  in  which  one  can  fill  in  dates  and  names 
and  be  done.  Every  program  is  different  as  is  each  engineering  organization. 
Therefore,  there  cannot  be  a universal  mi les tone/management  plan  any  more 
than  there  can  be  a universal  R-NET.  The  point  is  that  the  SREM's  approach 
to  software  requirements  development  and  validation  is  structured  and 
formalized  such  that  meaningful  milestones  can  be  readily  defined  -- 
milestones  that  are  specific  and  measurable. 


7.0  COST  AND  SCHEDULE  PLANNING 


* 


The  formalized  steps  of  SREM  and  the  specific  intermediate  milestones 
which  result  provide  a sound  basis  for  scheduling  and  bugeting  software 
requirements  development.  This  section  provides  models  and  guidelines  for 
estimating  the  cost  of  developing  software  requirements  using  SREM.  The 
experience  data  base  is  as  yet  too  small  to  fully  calibrate  and  validate  the 
models;  however,  cost  data  has  been  collected  on  three  SREM  applications, 
and  the  correlation  between  that  data  and  the  cost  models  is  provided. 

SREM/REVS  is  a composite  of  a methodology,  language  and  supporting 
tools  that  allow  identification  of  key  milestones  in  a development  program 
and  which  generates  an  output  whose  size  is  realistically  quantifiable. 
Consider  a requirements  paragraph  written  in  English.  It  can  be  measured 
by  the  number  of  words  or  sentences,  but  these  parameters  do  not  scope  the 
content  in  any  meaningful  way.  Conversely,  requirements  written  in  RSL 
consist  of  specific  elements  such  as  R_NETs,  ALPHAS,  INTERFACES,  DATA,  etc. 
While  these  elements  may  vary  slightly  in  length,  size  or  implied  complexity, 
they  do  offer  a reasonably  consistent  set  of  parameters  for  specification 
sizing.  Given  the  magnitude  of  the  product  to  be  developed,  then  cost  can 
be  related  directly  to  the  work  to  be  accomplished  to  generate  that  product. 

SREP  cost  and  schedule  estimation  involves  establishing  cost  parameters 
for  each  RSL  ELEMENT  or  ELEMENT_TYPE.  These  parameters  are  developed  in 
much  the  same  manner  as  cost-per-unit  code.  After  a cost-per-element  or 
cost-per-element-type  is  derived  (based  on  previous  experience),  then  the 
accuracy  of  SREP  cost  and  schedule  estimates  becomes  a direct  function  of 
the  initial  understanding  of  the  problem.  This  situation  is  somewhat 
analogous  to  software  development,  i.e.,  accurate  cost-per-instruction  data 
is  useful  to  the  extent  that  initial  estimates  of  how  many  statements  will 
be  required  is  accurate. 

Using  this  approach  to  costing,  there  is  a necessity  for  an  early  and 
accurate  estimate  of  the  number  of  RSL  elements  required  for  a given  program. 
In  fact,  this  was  one  of  the  underlying  Issues  in  the  definition  of  Phase  I 
of  the  SREM.  In  this  phase  a quick  response  primitive  construct  of  the 
major  elements  is  completed.  Phase  I can  be  conducted  on  paper,  or  entered 
into  a working  data  base  with  machine-processable  RSL,  allowing  maximum  use 
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of  REVS  automated  graphics  capabilities.  Either  method  provides  for 
rapid  collection  of  information  for  end  product  sizing. 

7.1  EXPERIENCE  TO  DATE 

SREP  has  been  applied  to  several  small  efforts  (less  than  1-2  man- 
months)  and  to  two  medium  scale  projects  (1-2  man-years  in  duration).  The 
small  applications  were  demonstration  type  problems  that  focused  on  speci- 
fic subsets  of  SREM/REVS  capability.  One,  referred  to  as  Project  B,  was 
developed  to  the  extent  that  its  resource  utilization  data  is  meaningful. 
Three  data  points  are  therefore  available  to  assist  preliminary  formulation 
of  SREM  cost  models: 

• Track  Loop  was  the  first  medium  scale  SREM  application.  Track 
Loop  represents  a well-defined  system  for  which  a specifica- 
tion of  reasonably  high  quality  was  available.  The  system's 
mission  is  a subset  of  a full  ballistic  missile  point  defense 
role:  included  are  the  tracking,  resource  management  and 
scheduling  functions.  A software  implementation  of  Track 
Loop  requirements  is  estimated  to  be  25-40K  of  program  source 
statements. 

• Project  A,  the  second  medium  level  effort,  generated  the 
requirements  for  a tactical  weapons  system.  The  weapons 
system  was  distributed  in  nature  and  featured  various  types 
of  air  defense  subsystems  interacting  with  multiple  airborne 
attackers  and  offensive  missiles.  This  effort  was  conducted 
early  in  the  project's  Concept  Definition  phase;  consequently, 
requirements  were  modified  many  times  due  to  changes  at  the 
system  level.  It  was  estimated  that  when  the  Project  A 
software  subsystem  is  implemented,  it  will  contain  approxi- 
mately 200,000  source  statements. 

• Project  B was  the  only  small  demonstration  problem  of  suffi- 
cient scope  to  include  for  cost  and  schedule  information. 

The  system  configuration  consisted  of  a data  processor  and 
radar  whose  functions  were  to  collect  telemetry  data  from 
airborne  weather  balloons.  System  operation  was  such  that 
the  data  processor  controlled  an  uplink  from  the  radar  to  the 
weather  balloon  for  beacon  tracking  purposes  and  a downlink 
for  the  monitoring  of  temperature,  wind,  pressure,  etc.,  at 
various  altitudes.  No  estimates  have  been  made  on  the  size 
of  the  software  subsystem  for  Project  B. 

Table  7.1  itemizes  the  resources  expended  on  each  of  these  three 
projects  according  to  the  phases  of  the  SRE  Methodology.  Note  that  the 
small  demonstration  effort  (Project  B)  is  listed  in  man-hours  as  opposed 
to  the  other  two  projects  which  are  listed  in  man-weeks. 
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Table  7.1  Resources  Expended  on  Completed  SREM  Applications 


Each  of  the  three  efforts  were  performed  using  a uniform  staffing 
profile.  Project  B was  conducted  by  a single  engineer  during  a 3-week 
period.  Of  the  two  larger  efforts,  both  were  conducted  at  a steady  state 
level  of  either  2 or  3 engineers.  At  the  start  of  both  efforts,  one 
engineer  generated  the  definition  of  subsystem  elements  and  derived  the 
Initial  R_NETs  connecting  the  input  and  output  interfaces.  The  staffing 
levels  were  then  increased  and  maintained  at  a constant  rate  throughout 
the  duration  of  each  effort. 

7.2  COST  MODEL  FORMULATION 

Two  approaches  to  formalizing  a SREM  cost  model  have  been  formulated. 
The  first  is  theoretical  and  will  require  significant  data  for  accurate 
calibration.  The  second  is  less  complex  and  can  serve  as  a interim  approach. 
Both  use,  as  a key  element,  the  basic  resources  necessary  to  generate  a 
measurable  quantity  of  output  and  both  were  developed  to  meet  the  following 
objecti ves . 

• End  product  size  estimates  must  be  generated  as  an 
initial  part  of  Phase  I of  the  SREP  methodology. 

• Overall  program  resource  requirements  must  be  decomposed 
and  allocated  to  defined  intermediate  milestones. 

7.2.1  Cost  Model  1 (CM!) 

Because  Software  Requirements  Engineering  is  basically  a creative 
process,  it  closely  parallels  software  development;  this  implies  a cost 
relationship  of  the  form 

CostSR[  = £ (BCUj  • ^ IC(j)*CSR 


where 

BCUj  = Basic  cost  unit  (man-months)  per  methodology  phase 

P = Number  of  methodology  phases  to  be  conducted 

ICi j = The  set  of  intangible  factors  that  modify  the  BCU 

C<.R  = Cost  of  developing  peripheral/supporting  items 
necessary  for  completion  of  the  SRE  effort. 
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This  relationship  shows  that  each  phase  of  the  SREP  methodology  has 
associated  with  It  a certain  basic  cost.  The  basic  cost  reflects  the 
resources  necessary  to  complete  that  phase  under  average  conditions.  Since 
average  conditions  tend  to  be  atypical  on  most  projects,  the  basic  cost  of 
each  phase  can  be  adjusted  (either  higher  or  lower)  by  the  values  of  three 
parameters  that  reflect  a set  of  intangible  (or  off-normal)  constraints. 
Supporting  items  developed  external  to  the  mainline  requirements  engineering 
function  (e.g. , tactical  algorithms)  are  added  directly  to  the  adjusted 
basic  cost  to  determine  overall  resource  requirements. 

7. 2. 1.1  Basic  Cost  Units 

The  Basic  Cost  Unit  for  software  requirements  is  calculated  in  terms 
of  the  resource  expenditure  related  directly  to  the  size  of  an  intermediate 
or  end  product.  Figure  7-1  presents  a chart  of  the  phases  of  the  SRE  method- 
ology. The  Basic  Cost  Unit  associated  with  each  phase  is  related  to  specific 
measures  of  the  quantity  of  output  from  that  phase.  For  example,  in  Phase  III, 
the  number  of  ALPHAs  and  DATA  items  drive  the  Basic  Cost  for  that  phase. 
Although  many  different  functions  are  performed  in  this  phase,  and  other 
specifications  items  generated,  these  are  the  two  controlling  parameters. 
Therefore,  given  an  estimate  of  the  number  of  ALPHAs  and  DATA  quantity 
required,  the  Basic  Cost  of  Phase  III  can  be  determined. 

The  upper  section  of  Figure  7-2  defines  the  postulated  relationship 
between  the  BCU  and  the  number  of  RSL  elements  to  be  specified.  As  shown, 
the  curve  is  anticipated  to  increase  as  a damped  exponential  prior  to 
Point  N;  the  basic  shape  of  the  curve  will  then  change  to  a fast-rising 
exponential  form.  This  indicates  that,  up  to  a certain  point,  the  addition 
of  one  element  to  the  data  base  will  cause  an  increase  in  resource  expendi- 
tures at  less  than  a linear  rate.  Once  Point  N has  been  reached,  any 
additional  element  added  to  the  data  base  will  cost  more  than  one  unit  of 
resources.  The  value  RQ  accounts  for  startup  time  and  indicates  that  even 
for  limited  productivity  the  resources  expended  in  learning  and  understanding 
the  problem  are  the  dominant  factor. 
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PHASE  I.  DEFINITION  OF 

SUBSYSTEM  ELEMENTS 


The  second  half  of  Figure  7-2  shows  the  correlation  of  the  three 
available  data  points  for  SREM  Phase  I application  on  Projects  A and  B 
and  for  TLS.  For  Phase  I,  the  independent  parameter  (Se)  was  assumed  to 
be  a linear  function  of  the  number  of  MESSAGES , RJIETs,  and  ALPHAs.  The 
count  of  the  first  two  elements  have  been  combined  with  the  number  of 
ALPHAs  divided  by  two  to  indicate  that  approximate  I y 50  percent  of  the 
ALPHAs  are  defined  in  Phase  I,  and  the  remaining  50  percent  completed  in 
Phase  III. 

Table  7.2  presents  the  number  of  requirement  elements  for  each  of 
the  three  projects.  From  this  information,  the  exact  number  of  elements 
generated  in  each  SREM  phase  can  be  determined.  The  three  data  points 
are  plotted  in  Figure  7-2  in  man-weeks  versus  the  effective  number  of 
elements  generated.  As  shown,  these  results  potentially  conform  to  tne 
expected  shape  of  the  relationship  curve.  By  selecting  the  appropriate 
combination  of  cost  elements,  this  exercise  could  be  completed  for  each 
phase.  This  would,  however,  be  somewhat  academic  due  to  the  limited 
number  of  data  points  currently  available. 

7. 2. 1.2  Intangible  Factors 

There  are  a number  of  intangible  factors  that  will  affect  the  cost 
of  a creative  development  process.  For  the  purposes  of  SREM  Cost  Model 
One,  all  of  the  intangible  factors  have  been  grouped  into  three  categories: 

1)  System  Specification(s)  Quality  - How  "good"  is  the  SRE 
input  information? 

2)  DP  Subsystem  Complexity  - Will  the  complexity  of  the  end 
product  be  "normal",  relatively  simple  or  complicated  and 
highly  interactive? 

3)  Development  Factors  - Is  there  something  about  the  way  the 
job  must  be  performed  that  will  impact  the  cost? 

Given  these  categories  the  next  question  is  how  can  they  be  quanti- 
fied or  rated  for  a specific  program?  Since  the  rating  will,  of  necessity, 
be  intuitive,  there  is  no  easy  answer.  To  reduce  some  of  the  ambiguity, 
a second  level  breakdown  of  the  contributing  factors  in  each  main  category 
has  been  defined  (Table  7.3).  The  subcategories  indicate  the  general  class 
of  factors  that  should  be  considered  under  each  major  grouping. 
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Table  7.2  Elements  Generated  Per  Project 


ELEMENT 

TYPE 

TLS 

PROJECT 

A 

PROJECT 

B 

R_NETS 

7 

55 

2 

ALPHAS 

30 

148 

13 

DATA  ITEMS 

100 

333 

68 

MESSAGES 

13 

47 

7 

INTERFACES 

6 

32 

4 

• Input 

(3) 

(19) 

(2) 

• Output 

(3) 

03) 

(2) 

FILES 

10 

33 

3 

ENTITY_CLASSES  & 
ENTITY_TYPES 

8 

7 

5 

Table  7.3  Intangible  Factors 


• System  Specif lcation(s)  Quality 


• Interface  Definitions 


• Functional  Integrity 


• Performance,  Timing, 
Accuracy 

• Environment  Description 


• General  Organization, 
Consistency,  Completeness, 
Level  of  Detail , etc. 

• DP  Subsystem  Complexity 


Have  the  DP  Interfaces  with  other  sub- 
systems been  adequately  specified? 

Has  the  required  processing  been  logi- 
cally connected  or  specified  as  an 
unrelated  series  of  activities  to  be 
(somehow)  performed? 

Are  there  quantitative  measures  for 
'how  well'  the  software  must  perform? 

Quality  of  the  specification  of  the 
environment  external  to  the  overall 
system  (of  which  the  software  is  a 

part) 

Aggregated  assessment  of  all  factors 
other  than  the  above. 


• Type 


• Threat 


• Interactions 


• State-of-the-Art 


• Development  Factors 


Batch  vs  distributed,  off-line  vs 
real-time,  etc. 

Effects  of  the  system  mission,  threat 
size,  complexity,  and  Imposed  time- 
lines 

Assessment  of  the  logical  flow,  con- 
nectivity, number  of  paths  and  branches,  etc. 

Is  this  a new  type  of  system  with 
unknown  control  processes  or  does  all 
required  technology  already  exist? 


• Personnel  Talent 


• Motivation 


• Management  Procedures 


• Artificial  Schedule 
Constraints 


• Key  Element  Availability  - 


Assessment  of  the  basic  capabilities 
of  the  contributing  individuals 

Any  unusual  factors  that  add  to,  or 
subtract  from,  personnel  motivation 

Effects  of  government  Imposed  standards, 
documentation  reporting  schemes,  con- 
figuration management,  etc. 

External  requirements  to  proceed  faster 
than  a realistic  timeline  or  the  delay 
of  key  Inputs 

Assessment  of  the  access  to,  or 
availability  of,  computers,  systems 
engineers,  input  data,  skill  centers, 
technology  Information,  etc. 


A scale  of  zero  to  10  was  selected  to  quantify  each  major  group: 


10  highest  positive  value,  subtracts  from  cost 

Scale 5 average,  no  effect 

0 worst  case,  adds  to  cost 

The  Basic  Cost  Unit  was  defined  as  the  cost  of  an  'average'  effort.  If  all 
1,  intangible  factors  were  rated  at  five,  the  BCU  would  not  change.  Values 

higher  than  five  would  decrease  the  net  cost  and  values  lower  than  five 
would  cause  an  overall  increase. 

Table  7.4  shows  the  composite  intangible  rating  for  the  three  SREM 
projects  conducted  to  date.  Each  rating  was  determined  after  program 
completion  following  the  guidelines  in  Table  7.3.  As  shown.  Project  A, 
which  was  conducted  during  Concept  Definition,  was  rated  relatively  low. 

The  system  specification  do*  iments  were  not  firm  and,  with  each  update, 
additional  effort  was  neces..a.'y  to  revise  the  evolving  DP  requirements. 
Developmental  factors  were  also  rated  low  because  of  a large  geographical 
separation  between  the  various  participating  agencies  plus  a limited 
access  to  the  necessary  computer  resources. 

For  these  three  projects  the  values  of  the  intangible  ratings  were 
assessed  to  be  constant  across  all  methodology  phases.  Although  the  basic 
cost  equation  allows  for  variable  ratings,  the  pertinent  chararacteristics 
of  these  SREM  applications  did  not  vary  sufficiently  per  phase  to  impact 
the  assigned  values. 

Figure  7-3  depicts  the  predicted  impact  relationship  of  the  IC  ratings 
on  the  Basic  Cost  Units.  As  shown,  the  predicted  relationship  follows  the 
theory  that  'the  bad  outweights  the  good'.  For  example,  if  Development 
Factors  were  very  constraining  (rated  at  1),  then  the  value  of  a good 
system  specification  could  be  more  than  offset  by  a possible  100  percent 
Increase  due  to  poor  Development  Factors. 

7. 2. 1.3  Cost  of  Supporting  Elements 

There  are  two  major  contributors  to  overall  cost  that  can  be  classi- 
fied as  supporting  or  peripheral  activities:  SETS  (simulation  driver) 
development  and  algorithm  development. 
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Table  7.4  Rating  of  Intangible  Factors 


ILS 

PROJECT  A 

PROJECT  B 

System  Specification  Quality 

7 

2 

7 

DP  Subsystem  Complexity 

7 

5 

8 

Development  Factors 

6 

3 

9 

SETS  Is  a generic  name  for  the  driver  software  for  both  the  REVS 
generated  functional  and  analytic  simulators.  Since  the  required  SETS 
processing  is  applications  and  program  peculiar,  there  are  few  a priori 
criteria  for  its  development  cost.  Also,  the  specification  and  design  of 
SETS  falls  in  the  domain  of  systems  engineering.  This  occurs  because  it 
is  at  that  level  that  the  environment  and  its  effects  are  studied/formu- 
lated in  the  most  detail.  SETS  costs  have,  therefore,  been  somewhat 
decoupled  from  the  overall  software  requirements  engineering  cost  model 
and  can  be  estimated  using  classical  engineering  and  software  development 
rules. 

The  Gaimia  models  that  form  the  REVS  analytic  simulator  demonstrate 
the  existence  of  a feasible  mathematical  solution.  There  are  two  separate 
activities  involved  in  Gamma  development:  first,  the  mathematical  formu- 
lation of  the  algorithms,  and  secondly,  their  implementation  as  PASCAL 
procedures.  The  first  activity  is  best  performed  by  experts  in  the  various 
disciplines  associated  with  technology  or  weapons  systems  operations.  Costs 
associated  with  this  activity  are,  therefore,  provided  by  the  individuals 
directly  involved  and  are  assumed  to  be  inputs  to  the  SRE  cost  estimation 
scheme.  Algorithm  implementation  as  RSL  GAMMAs,  therefore,  becomes  a 
standard  software  development  cost  estimation  process. 

7.2.2  Cost  Model  2 (CM2) 

The  approach  to  a validated  SREM  cost  model,  as  described  in  the  previous 
section,  is  somewhat  ambitious.  Accurate  collection  of  the  necessary  data 
represents  one  problem  area.  The  lead  time  necessary  to  generate  and 
calibrate  the  information  represents  a second  potential  constraint.  An 
interim  cost  model,  that  is  simplier  than  CM1  and  can  be  used  as  the  cost 
estimating  baseline  in  the  near  term  is  presented  here. 

For  Cost  Model  2,  resource  expenditures  for  SREM  applications  are 
divided  into  two  components. 

Cost  - Costpunct^Qnai  ReqUirements  + ^ostPerformance  Requirements 
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Resources  for  generating  the  functional  and  performance  requirements  are 
again  calculated  based  on  the  total  number  of  RSL  elements  that  must  be 
developed.  For  the  development  of  functional  requirements,  the  primary 
RSL  elements  are: 

• ALPHAS 

• R_NETS 

• DATA 

t INTERFACES 

• MESSAGES. 

Figure  7-4  presents  a preliminary  correlation  of  the  results  for  this 
approach  on  the  three  projects  completed  to  date.  The  dashed  line 
represents  a postulated  curve  fit.  Note  that  all  resource  expenditures 
were  used,  including  the  simulation  driver  development  cost. 

Given  the  overall  cost  of  the  functional  requirements,  a finer  break- 
down is  needed  for  each  intermediate  milestone  or  SRE  methodology  phase. 
Referring  to  Table  7.5,  three  logical  breakdowns  of  the  activities  are 
indicated.  At  the  end  of  the  first  three  methodology  phases,  a complete 
description  of  the  R_NETS,  ALPHAS,  etc.,  that  constitute  the  functional 
requirements  have  been  completed.  At  the  end  of  Phase  5,  the  functional 
models  have  been  developed  and  requirements  testing  or  dynamic  validation 
conducted.  The  third  set  of  activities  are  miscellaneous  in  nature  and 
are  conducted  throughout  the  course  of  the  development  with  the  exception 
of  generation  of  the  simulation  driver.  For  the  purpose  of  cost  and 
scheduling  the  development  process  through  the  static  validation,  which  occurs 
at  the  end  of  SREM  Phase  3 requires  approximately  30  percent  of  the  total  cost 
of  generating  the  functional  requirements.  Dynamic  validation  requires 
approximately  40  percent  of  the  total  required  resources.  Miscellaneous 
activities  encompass  the  remainder  of  the  cost,  with  development  of  the 
simulation  driver  beinq  the  most  expensive  of  these  activities. 

Given  the  total  cost  for  developing  functional  requirements  (see 
Figure  7-4),  then  the  30-40-30  percentages  can  be  used  to  determine  the 
cost  for  each  of  the  three  milestones  within  the  development.  A further 
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Figure  7-4  Cost  Summed  Over  Major  Elements 


Table  7.5  Percentage  Cost  Breakdown 


TLS 

PROJECT  A 

PROJECT  B 

MWs 

% 

MWs 

of 

h 

MHs 

% 

I. 

Definition  of  Subsystem 
Elements 

2 

4.2 

13 

12.0 

3 

3.5 

II. 

Evaluation  of  Kernel 

5 

10.3 

4 

3.7 

8 

9.3 

III. 

Completion  of  Func- 
tional Description 

10 

20.8 

15 

13.9 

11 

12.8 

Ml 

Static  Validation 

17 

35.3 

32 

29.6 

22 

25.6 

V. 

Development  of 

Functional  Models 

12 

25.0 

22 

20.4 

8 

9.3 

Requirements  Testing 

6 

12.5 

25 

23.1 

24 

27.9 

M2 

Dynamic  Validation 
(Functional ) 

18 

37.5 

47 

43.5 

32 

37.2 

IV. 

Informative  Material 
and  Traceability 

4 

8.4 

12 

11.1 

0 

0 

IV. 

Docianentatlon 

1 

2.1 

2 

1.9 

8 

9.3 

Simulation  Driver 

8 

16.7 

15 

13.9 

24 

27.9 

Misc.  Activities 
(Subtotal ) 

13 

27.2 

29 

26.9 

32 

37.2 

TOTAL 

48 

100 

108 

100 

86 

100 

breakdown  can  be  formulated  to  meet  Milestone  1,  static  validation.  Phase 
1 Is  basically  the  initial  definition  of  the  R_NETS,  the  connection  of  the 
Input/Output  INTERFACES  and  definition  of  the  preliminary  or  high  level 
ALPHAS.  In  Phase  2 this  information  is  entered  into  the  REVS  data  base. 
Then,  in  methodology  Phase  3,  the  functional  description  is  completed  with 
all  ALPHAS  defined  to  the  lowest  required  level  and  all  DATA  items  defined. 
These  three  activities  are  clearly  interrelated.  The  greater  the  amount 
of  time  and  resources  expended  in  Phase  1 then  a corresponding  smaller 
amount  of  resources  must  be  expended  in  Phase  3 to  complete  the  functional 
description.  The  SREM  program  manager  has  the  discretion  of  applying 
the  majority  of  the  resources  in  Phase  1 or  Phase  3 depending  on  the 
particular  problem  or  application. 


Required  costs  for  development  of  Performance  TESTs  follows  the  same 
philosophy  as  that  described  above  for  SREM  functional  requirements  defini- 
tion. To  date,  detailed  Performance  TESTs  have  been  generated  only  as  a 
result  of  specific  demonstration  problems.  None  of  the  three  projects 
addressed  the  full  range  of  performance  necessary  for  a complete  specifica- 
tion. At  this  point,  no  measured  data  exists  to  assist  identification  of 
the  major  RSL  elements  that  will  quantify  the  expected  cost  of  Performance 
TESTs. 


8.0  MANAGEMENT  CONTROL 


The  Software  Requirements  Engineering  activity  must  interface  with 
other  activities  during  the  system  development  phase.  Figure  8-1  explains 
the  major  interests  shared  by  SRE  with  these  other  activities.  The  key 
interactions  may  be  sumnarized  as  follows: 

• SRE  supports  SE  in  system  definition  by  accepting  the  speci- 
fications and  pointing  out  deficiencies. 

• SRE  may  question  the  subsystem  allocation  because  of  implemen- 
tation problems. 

• SRE  participates  in  the  overall  system  cost/schedule  planning 
and  control  by  providing  status  data  to  SE  and  visibility  to 
Process  Design. 

• SRE  must  work  with  the  other  subsystem  engineering  activities 
to  define  interfaces  to  a functional  level.  Process  Design 
can  work  to  design  the  detail  interfaces.  When  a referee 

is  needed  the  SE  must  decide  interface  issues. 

• SRE  defines  the  processing  via  software  requirements  which 
may  be  modified  if  real-time  implementation  is  a problem. 


8.1  CONTROL  MECHANISMS 

Management  of  SREM  can  be  viewed  as  a two-level  process.  REVS  pro- 
vides certain  direct,  automatic  control  of  the  product  under  development 
(the  software  requirements) . As  described  in  Table  8.1,  this  frees  manage- 
ment to  focus  on  higher  level  issues  and  the  implementation  of  REVS.  With 
a validated  REVS,  implementation  of  its  control  features  is  completely 
mechanical  and  can  be  delegated  with  confidence.  In  particular,  the  following 
observations  can  be  obtained  from  Table  8.1: 

• At  each  level  the  manager  can  focus  on  intent,  softness  of 
decisions,  level  of  detail  and  schedule  performance. 

• At  the  BETA,  GAMMA  and  PATH/PERFORMANCE  levels,  cost  perfor- 
mance becomes  important.  Overkill  must  be  avoided  by  main- 
taining pressure  to  use  the  simplest,  cheapest  models  which 
will  do  the  job.  (Thus,  level  of  detail  is  an  issue  here  also.) 

• At  the  GAMMA  level  the  manager  must  assess  real-time  feasi- 
bility even  though  the  GAMMA  models  are  not  real-time. 
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Table  8.1  SREM  Focus  of  Management  Control  on  Substantive  Issues 


• Previously,  managers  had  to  strain  to  get  the  kind  of 
visibility  easily  obtained  with  SREM/REVS. 

The  major  managerial  issues  identified  in  Table  8.1  require  mechanisms 
outside  of  REVS.  These  are  the  more  widely  used  managerial  controls,  and  are 
much  more  effective  when  based  on  the  timely,  complete,  and  organized  infor- 
mation provided  by  REVS.  The  kinds  of  control  mechanisms  used  for  these 
issues  are  shown  in  Table  8.2  and  are  summarized  below: 

t Internal  reviews  can  be  used  to  establish  confidence  in  the 
software  requirements  by  addressing  items  checked  in  the  Table. 

• Starting  with  a parametric  cost  model,  projected  cost  can  be 
estimated  as  actual  parameter  values  are  determined  (e.g., 
number  R_NETs,  ALPHAs,  etc.). 

• Earned  value  as  a measure  of  progress  toward  each  milestone 
can  be  used  in  the  C-SPEC  sense  to  evaluate  cost/schedule 
performance  in  a continuous  fashion.  Earned  value  can  be 
quantified  by  usina  number  of  ALPHAS,  BETAs,  GAMMAs,  PATHS, 
TESTs,  etc.  weighted  by  complexity  factors. 

• The  milestone  schedule  is  a standard  schedule  performance 
control  best  implemented  by  public  display. 

• Reviews  with  the  system  engineer  should  help  understand 
questions  of  intent  and  softness  of  decisions  plus  adequacy 
of  level  of  detail . 

• The  process  designer  should  be  involved  in  reviews  of  level 

of  detail  and  real-time  feasibility  (includes  storage  capacity). 

8.2  CHANGE  CONTROL 

The  process  of  change  control  is  a critical  one  on  a large,  complex 
system  development  activity.  Figure  8-2  shows  how  collected  decisions  can  be 
folded  into  the  baseline  as  scheduled  updates.  The  updates  are  inserted 
at  points  in  the  schedule  where  they  are  likely  to  have  significant  inputs 
from  within  the  SRE  activity  arid  from  System  Engineering  and  Process  Design. 
They  also  follow  specific  measures  of  the  software  requirements,  namely  the 
initial  dynamic  evaluation  and  the  initial  feasibility  demonstration. 
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SECOND  MAJOR  UPDATE  (ALPHA/BETA/ GAMMA) 


8.3  ACCEPTANCE  OF  THE  SOFTWARE  REQUIREMENTS 

Both  the  System  Engineer  and  Process  Designer  must  accept  the  end 
product  software  requirements.  SREM  possesses  key  features  which  should 
assist  the  SRE  manager  in  effecting  this  buy-off.  These  are  explained  in 
Table  8.3  in  terms  of  answers  to  concerns  of  both  System  Engineering  and 
Process  Design. 
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9.0  CONCLUSIONS 


This  manual  has  explained  both  the  technical  and  management  considera- 
tions in  the  development  and  validation  of  software  requirements  using  the 
tools  and  techniques  of  SREM.  The  engineering  and  management  principles 
explained  here  are  not  actually  new  --  they  are  the  result  of  hundreds  of 
man-years  of  experience  and  observation  of  large-scale, real -time  software 
development.  The  discipline  of  RSL  and  the  power  of  REVS,  however,  are  new, 
as  is  the  formalization  of  the  detailed  steps  to  be  followed  in  their  use. 

This  manual  will  not  make  instant  engineers  or  managers  out  of  in- 
experienced people.  It  will,  however,  guide  the  experienced  engineer  and 
manager  in  the  application  of  RSL,  REVS,  and  SREM  techniques  to  obtain  a 
software  requirements  specification  which  is  superior  in  terms  of  the  basic 
qualities  of  a good  requirements  specification. 
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APPENDIX  A 

SAMPLE  DPSPR  - XI  TRACK  LOOP  EXPERIMENT 
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I.  INTRODUCTION 


1.0  PURPOSE  AND  SCOPE 

This  report  presents  the  preliminary  Data  Processing  Subsystem  Per- 
formance Requirements  (DPSPR)  for  t lie  Track  Loop  Experiment  (X-l).  The 
goals  for  this  experiment  are  presented  in  Section  2.0. 

The  primary  intent  of  this  document  is  to  provide  the  initiating 
input  to  the  Software  Requirements  Engineering  Methodology  which  will  sub- 
sequently produce  a Process  Performance  Requirements  (PPR)  specification 
for  the  Track  Loop  System  Data  Processing  Subsystem.  It  is  further  the 
intent  of  this  document  to  present  an  example  of  the  required  contents  and 
level  of  detail  of  a DPSPR  discussed  in  Reference  1.  As  such,  this  example 
will  provide  a more  concrete  basis  for  technical  exchange  between  the  Soft- 
ware Requirements  Engineering,  DPSPR  and  V&V  contractors . Such  interchange  is 
considered  necessary  to  arrive  at  a final  definition  of  the  required  form, 
contents  and  format  of  a DPSPR.  Part  II  of  this  report  constitutes  the 
example  DPSPR. 

1 . 1 The  Track  Loop  System 

The  Track  Loop  System  (TLS)  is  a subset  of  a Preliminary  Ballistic 
Missile  Defense  System  which  is  capable  of  nearly  autonomous  execution 
in  response  to  external  stimuli.  It  is  the  simplest  known  subsystem  with 
properties  of  interest  for  software  definition,  and  it  is  one  which  lias 
been  studied  extensively,  both  in  the  academic  literature  and  in  such 
practical  programs  as  Site  Defense.  Therefore,  it  has  been  selected  as 
the  testbed  for  supporting  experimentation  in  development  of  the  methodology 
for  software  requirements.  A pictorial  representation  of  the  TLS  is  provided 
in  Figure  A-l. 

1.1.1  Preliminary  Ballistic  Missile  Defense  System 

A Preliminary  Ballistic  Missile  Defense  System  (PBMDS)  has  been 
postulated  as  an  environment  in  which  the  TLS  would  execute.  It  is  a 
generalized  representative  of  the  class  of  systems  currently  in  develop- 
ment, and  is  particularized  for  the  TLS  through  representative  but  non- 
real  specifications  where  required. 
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The  top  level  flow  of  the  PBMDS  is  shown  in  the  functional  flow  block 
diagram,  Figure  A-2.  In  the  Conduct  Engagement  mode,  an  object  entering  the 
search  region  will  be  detected  and  designated,  tracked,  discriminated,  and 
engaged  (as  required)  in  defense  of  the  ground  facilities.  Those  functions 
are  implemented  through  the  Data  Processing  System  (DPS),  a radar  or  other 
sensor,  and  a means  of  neutralizing  hostile  objects.  For  the  purpose  of 
the  TLS,  only  the  radar  need  be  defined  in  detail;  other  system  elements 
are  identified  only  to  the  extent  that  they  impact  DPS  requirements. 


1.1.2  TLS  Requirements 

Functional  Requirements  on  the  TLS  would  normally  be  contained  in  a 
system  specification  (Level  1,  or  A in  MIL  STD  490  terminology).  If  soft- 
ware is  developed  from  the  requirements  provided  in  Section  II  of  this 
report,  and  if  that  software  is  to  be  installed  and  exercised  in  the  field, 
then  such  a system  specification  may  be  required.  In  the  interests  of 
both  economy  and  timeliness,  only  the  subsection  of  the  A Specification 
required  for  the  DPSPP.  is  provided  nere. 


1.1. 2.1  Initialization 

2 

The  TLS  shall  accept  C messages  for  initialization  with  the  following 
properties : 

a)  An  estimate  of  state  shall  be  generated  external  to  TLS  and  for- 
warded to  TLS  over  the  communication  channel  to  initiate  tracking. 

b)  If  an  object  corresponds  to  tiiat  estimate,  the  estimation  accuracy 
shall  be  such  that  the  expected  (1-sigma)  deviation  of  the  object 
from  a perfect  extrapolation  of  state  shall  be  in  accord  with 
Table  1-1. 

c)  Initialization  estimates  shall  be  provided  (handed  off)  at  a rate  not 
exceeding  150  per  second  over  any  interval  greater  than  50  milli- 
seconds . 

d)  The  total  number  of  handoffs  shall  not  exceed  1500. 

e)  The  total  number  of  real  objects  shall  not  exceed  300. 

f)  A handoff  may  be  an  estimate  on  a real  ouject  or  an  estimate  relating 

to  a state  at  which  no  object  is  located  (ghost).  Multiple  handoffs 
of  a single  object  may  be  generated. 

g)  Each  handoff  shall  consist  of  a unique  designator,  the  state  vector 
and  its  covariance  matrix. 
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Table  A. 2 Table  A.l  Handover  Errors  In  Radar  Face  Coordinates 


COORDINATE 

MINIMUM 

MAXIMUM 

UNITS 

R 

3 

5 

M 

U 

0.4 

0.6 

msine 

V 

0.03 

0.05 

msine 

R 

40 

55 

m/sec 

U 

2 

4 

msine/scc 

V 

2 

4 

msine/sec 

NOTES: 

1.  All  data 

2.  Handover 

1 -n 

altitude  ±.  65 

K meters 

I 

i 
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1.1. 2. 2 Termination 


a)  Redundant  images  of  objects  shall  be  dropped  from  track  in  order  to 
conserve  radar  resources.  The  probability  of  dropping  track  on  a 
non-redundant  image  shall  be  considered  in  determining  leakage. 

b)  Ghosts  shall  be  dropped  from  track  in  order  to  conserve  radar 
resources.  The  probability  that  a non-redundant  image  is  dropped 
as  a ghost  shall  be  considered  in  determining  leakage. 

c)  For  flight  safety,  no  track  pulse  shall  be  commanded  with  true  elevation 
angle  less  than  3° 

d)  Track  shall  be  dropped  in  response  to  an  external  command  rep»e- 
senting  handoff  to  another  defense  facility  or  successful  intercept. 

No  track  pulse  shall  be  transmitted  to  a designated  image  more  than 
100  milliseconds  after  such  a command  appears  at  the  TLS  port,  with 
probability  .3. 

1 . 1 . 2 . 3 Tracking 

a)  The  TLS  shall  generate  state  estimates  sufficient  to  support  discrimi- 
nation through  beta  estimation  accuracy  in  accordance  with  Figure  A- 4 
and  impact  point  prediction  in  accordance  with  Figure  A-5. 

Beta  is  required  in  the  system  for  a variety  of  purposes  at  different 
stages  in  the  engagement  of  an  object.  Eai'ly  in  track , it  is  used 
for  junk  rejection ; at  an  intermediate  state , it  foivns  a key 
element  of  discrimination  in  elimination  of  decoys  and  assessment 
of  the  danger  imposed  by  an  RV;  shortly  thereafter,  it  is  essential 
to  intercept  planning  in  estimating  the  intercept  point.  The  nee<is 
overlap  in  practice,  so  that  a common  ordi  ate  for  the  plot  of 
accuracy  requirements  is  needed.  But  each  of  the  aspects  of  use  of 
beta  dictates  a different  ordinate  at  the  system  level.  The  ordinate 
selected  in  Figure  A-4  is  time  in  track,  a par  meter  known  to  be 
useful  to  tee  Software  Requirements  Engineer,  and  as  useful  for 
the  systems-level  definition  as  any  of  the  ether  choices. 

Similarly,  Impact  point  prediction  is  used  initially  to  reject  cress 
traffic,  then  to  assess  the  threat  posed  by  an  RV;  in  some  schema , 
it  also  assists  discrimination.  The  first  might  oe  expressed  by  the 
system  engineer  in  terms  of  accuracy  against  track  energy,  the 
second  in  terms  of  time  to  connit  contcur  (which  is  in  turn  a 
function  of  RV  type , intercept  capabilities , and  other  parameters) . 
Again,  time  in  track  was  chosen  as  a convenient  ordinate  for  the 
error  requirements  in  Figure  1-5. 

b)  The  TLS  shall  generate  state  estimates  sufficient  to  support  object 
intercept  in  accordance  with  Figure  1-6  (TBD). 

c)  Leakage  is  here  defined  to  be  the  probability  that  all  images  of 
a real  object  entered  at  an  altitude  not  less  than  150K.  feet  are 
dropped  from  track  for  any  reason  other  than  the  minimum-elevation 
constraints  or  external  command  defined  in  1.1. 2. 2.  Leakage  in 
TLS  shall  not  exceed  .03. 
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1.1. 2. 4 Resource  Control 


a)  The  TLS  shall  commit  to  tracking  functions  not  more  than  1800  radar 
pulses  per  second,  using  not  more  than  25  kilowatts  ERP. 

b)  The  TLS  shall  commit  to  tracking  functions  not  more  than  2500  joules 
per  object.  ’ 

1.1. 2. 5 Data  Recording 

The  TLS  shall  provide  records  for  post  test  analysis  of  the  following 

data: 

a)  Time  of  handoff  and  designator  and  estimate  received. 

b)  Time  of  termination  of  track  on  each  designation  with  reason 
for  termination. 

c)  At  intervals  not  greater  than  100  milliseconds,  the  estimate  of 
state  for  each  designation  received  and  not  yet  terminated. 

That  estimate  shall  consist  of  the  following  data:  position, 
velocity,  a beta  estimation  parameter  and  estimates  of  the 
uncertainty  of  each. 

d)  At  intervals  not  greater  than  300  milliseconds,  the  usage  of 
radar  resources.  Thai  measure  shall  include:  radar  energy  profile 
and  DPS  estimates  of  expected  and  maximum  energy  commanded. 


2.0  SREP  OBJECTIVES  FOR  X-l 


a)  Demonstrate  the  scope,  contents  and  level  of  detail  of  the  DPSPR, 
described  in  Reference  1,  and  transmit  the  results  to  the  DPSPR 
contractors  for  their  evaluation. 

b)  Demonstrate  the  scope,  contents,  format,  and  level  of  detail  of 
PPR  Volume  I specified  in  Reference  2.  The  PPR  will  be  written 
in  preliminary  RSL  (see  Reference  4).  In  particular: 

1)  Evaluate  the  format  of  the  PPR  described  in  Reference  2 for 
completeness  and  adequacy. 

2)  Evaluate  the  adequacy  of  the  preliminary  RSL  definition  for 
stating  requirements. 

3)  Provide  the  PPR  for  evaluation;  in  particular,  the  form  and 
content  of  the  performance  requirements. 

4)  Evaluate  the  extent  of  the  traceability  of  the  PPR  to  the 
DPSPR. 

c)  Evaluate  the  steps  of  SREM  (see  Reference  3)  from  the  DPSPR  to  a 
PPR;  in  particular,  the  procedural  steps,  form,  and  content  of  the 
performance  allocation  activities. 

d)  Exercise  the  available  experimental  software  to  generate  portions 
of  the  PPR  (e.g.,  the  structure  segment  of  RSL). 


3.0  LIMITATIONS 


Two  primary  forces  limit  the  application  of  the  DPSPR  of  Section  II. 
The  first  is  the  result  of  excising  the  track  loop  from  the  total  PBMDS. 
Although  the  loop  is  nearly  self-contained,  it  has  extensive  interfaces 
both  in  terms  of  requirements  and  in  the  sense  of  implementation  with  other 
software  functions.  Consequently,  requirements  are  imposed  on  TLS  which 
originate  or  terminate  within  the  DPS  in  ways  and  to  an  extent  not  believed 
appropriate  for  a true,  functional  system. 

The  second  major  area  of  limitation  arises  from  the  novelty  of  the 
approach.  While  the  methodology  employed  is  believed  valid,  it  has  not 
yet  been  tried.  (In  fact,  this  experiment  is  its  trial.)  Consequently, 
it  is  likely  that  this  initial  DPSPR  will  be  found  to  be  incomplete  in  scrr_ 
materials  needed  for  the  PPR  and  for  software  development.  Every  effort  has 
been  made  to  anticipate  such  failings,  but  we  anticipate  methodologic  bugs 
in  the  same  way  we  would  expect  to  find  bugs  in  a new  compiler  or  other 
major  software  development. 

3 . 1 System  Objectives 

Isolation  of  TLS  from  PBMDS  was  artificial,  and  the  objectives  of 
Section  1.1  are  correspondingly  less  than  real.  The  selection  of  those 
objectives  was  based  on  simplicity  of  implementation,  expected  usefulness 
of  the  TLS  as  a testbed,  and  availability  of  comparison  criteria.  Since 
no  DPSPR  had  ever  been  prepared  before,  it  was  not  possible  to  select 
criteria  to  optimize  its  quality.  The  objectives  provided  are  believed 
to  be  good  for  generation  of  the  DPSPR,  but  cannot  be  shown  to  be  optimal. 

3.2  Allocation  to  DP 

Again,  the  absence  of  precedent  and  the  artificiality  of  the  TLS  make 
an  "optimum"  allocation  of  functions  unreasonable.  A complete  allocation 
is  provided,  which  is  believed  to  be  sufficient  for  the  experiment. 

3 . 3 Level  of  Detail 

The  objective  of  the  DPSPR  of  Part  II  is  to  provide  the  complete 
specification  required  for  the  PPR  Feasibility  Demonstration.  It  is  likely 
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that  some  of  the  material  will  prove  to  be  unnecessary;  it  is  certain  that 
not  all  data  presently  missing  will  be  required  before  initiating  work  on 
Volume  I of  the  PPR.  Therefore,  revisions  are  planned  both  to  complete 
specification  of  the  requirements  and  to  delete  data  found  to  be  non-essential. 

3 . 4 Formulation  of  DP  Requirements 

The  X-l  DPSPR  defines  some  data  in  a form  and  to  a depth  we  feel  to  be 
undesirable.  In  particular,  efforts  are  now  under  way  to  express  require- 
ments on  Redundant  Track  Elimination  in  terms  of  total  radar  energy  per 
object.  Converting  both  redundant  tracking  and  other  explicit  requirements 
to  a derivable  form  will  be  an  objective  for  revisions  of  the  DPSPR. 

3 . 5 Corollary  Documents 

The  DPSPR  is  one  document  in  a family  required  to  develop  the  Process 
Performance  Requirements  (PPR).  For  the  TLS,  tne  other  documents  are: 

• TLS  System  Requirements 

• TLS  Radar/DPS  Interface  Specification 

• TLS  C^/DPS  Interface  Specification 

• TLS  Radar  Performance  Specification* 

• TLS  Environment  and  Threat  Model  Definition.* 

The  system  requirements  are  sketched  in  Section  1.1  above.  The  starred  (*)  docu- 
ments in  this  family  are  not  yet  prepared. 

For  the  purposes  of  development  of  the  PPR,  the  absence  of  the  docu- 
ments is  believed  to  be  less  than  critical.  For  the  X-l  effort,  the  contents 
of  the  missing  specifications  are  subsets  of  the  corresponding  Terminal 
Defense  Program  (TDP)  documents.  Therefore,  the  required  information  for 
the  PPR  is  available  from  TDP  documentation.  However,  a property  of  the 
methodology  is  its  recognition  that  not  all  specifications  ultimately  required 
to  support  software  design  will  be  available  early  in  that  design  effort. 

To  the  extent  that  the  TLS  documentation  corresponding  to  initiation  of  a 
PPR  is  required,  the  TDP  documents  are  excessive.  Thus,  there  is  an  effort 
required  as  a part  of  the  ongoing  work  to  edit  the  TDP  material  to  the 
specific,  appropriate  contents  for  the  stage  of  development  represented  by 
the  DPSPR.  That  work  is  under  way  on  the  Radar/DPS  Interface  specification, 
and  will  soon  be  undertaken  on  the  other  elements  of  the  DPSPR  package. 
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II.  DATA  PROCESSING  SUBSYSTEM 
PERFORMANCE  REQUIREMENTS  - TRACK  LOOP  SYSTEM 


1.0  SCOPE 

This  specification  establishes  the  functional,  performance,  design 
and  test  requirements  for  the  Track  Loop  System  (TLS)  to  the  extent 
necessary  to  develop  the  Process  Performance  Requirements  (PPR)  for  the 
Data  Processing  Subsystem  (DPS)  portion  of  tne  system.  The  TLS  is  a test 
configuration  of  an  integral  element  of  a Preliminary  Ballistic  Missile 
Defense  System  (PBMDS). 

The  primary  objective  of  this  specification  is  to  constrain  the  DPS 
so  that  it  fulfills  the  intended  obligations  to  the  functions  and  perfor- 
mance of  the  overall  TLS  of  which  it  is  a part.  To  accomplish  this,  this 
specification 

• identifies  the  TLS  mission  and  performance  goals. 

e identifies  the  various  subsystems,  their  functional  capa- 
bilities, and  the  interfaces  between  the  Data  Processing 
Subsystem  and  each  of  the  others. 

t allocates  a portion  of  the  system  performance  to  the 
Data  Processing  Subsystem. 

• describes  the  system  operational  design,  i.e.,  how  the 
subsystems  are  to  be  used  in  order  to  achieve  the  system 
performance  goals  by  utilization  of  the  subsystem  capa- 
bilities. 

This  specification  provides  the  technical  basis  for  the  development  of  the 
DPS,  but  is  not  a TLS  system  specification. 
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2.0  APPLICABLE  DOCUMENTS 


DPSPR__Content  Requirements,  TRW  Report  27332-6921-003,  (CDRL  A004), 

Revision  1,  December  12,  1975. 

TLS  System  Requirements,  (Part  I,  Section  1.1  of  this  report). 

TLS  Radar/DPS  Interface  Specification  TRW  Report  No.  27332-6921-012 
2 

TLS  C /DPS  Interface  Specification  TRW  Report  No.  27332-6921-013 
TLS  Radar  Performance  Specification 


TLS  Environment  and  Threat  Model  Definition 


3.0  DATA  PROCESSING  SUBSYSTEM 


The  TLS  is  defined  in  [2.2]  (Part  I,  Section  1 . 1 of  this  report). 

Section  1.1.2  provides  the  system  requirements,  while  Figure  A-l  represents 

the  operation  of  the  system.  TLS  consists  of  a radar  and  a data  processor, 

2 

and  receives  input  data  from  radar  echoes  and  from  interface  with  the  C 
system.  A model  of  the  system  environment  is  to  be  provided  as  [2.6]. 

Within  the  TLS,  the  radar-data  processor  interface  specification  is  to  be 
[2.4],  while  the  C^/DPS  interface  will  be  defined  in  [2.3].  The  radar  models 
will  be  in  [2.5]. 

The  TLS  DPS  has  been  allocated  requirements  from  those  established  on 
the  TLS  as  a whole.  The  resulting  requirements  on  the  DPS  are  defined  in 
Section  3.2  of  this  DPSPR.  Traceability  of  the  DPSPR  requirements  to  the 
TLS  requirements  is  shown  in  Figure  A-l.  All  TLS  requirements  not  allocated 
to  the  DPS  are  satisfied  by  the  radar.  Quantitative  verification  of  the 
sufficiency  of  the  allocation  will  be  undertaken  in  the  preparation  of  the 
PPR. 

3.1  Traceabi 1 i ty 

Figure  A-l  is  the  traceability  matrix  for  this  DPSPR,  and  illustrates 
the  relationship  between  the  TLS  requirements  [2.2],  and  the  DPS  requirements 
of  Section  3.2.  It  also  depicts  the  allocation  of  portions  of  system  require- 
ments to  the  radar;  not  all  of  that  allocation  is  clearly  visible  in  the 
interface  specification,  some  of  it  being  located  in  [2.5], 

The  function  of  the  traceability  matrix  is  twofold:  to  locate  the  sub- 
system requirements  derived  from  each  system  requirement , and  to  facilitate 
recognition  that  each  DPS  requirement  originates  from  an  appropriate  source. 

The  first  function  is  insurance  that  the  DPSPR  (and  its  counterparts  for  other 
subsystems)  are  sufficient  to  embody  the  system  requirements,  while  the  second 
verifies  that  no  gratuitous  requirements  have  been  introduced. 

To  determine  the  source (s)  of  a DPS  requirement,  the  appropriate  row  is 
located  in  the  left-hand  column.  Reading  across  the  row,  an  entry  of  "C" 
indicates  that  virtually  complete  satisfaction  of  the  system  requirement  for 
that  column  is  provided.  A "P"  indicates  that  a portion  of  the  system  require- 
ment is  there  satisfied.  Scanning  the  entire  cliai't,  one  finds  that  the  DPS 
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Figure  A-l  Requirements  Traceability  Matrix 


requirement  to  satisfy  the  interface  specification  is  not  traceable  to  the 
system  requirements ; however , it  is  clearly  required , and  is  clearly  in- 
appropriate for  the  system  specification. 


Determining  the  inpact  of  a system  requirement  on  the  subsystems  is 
constructive  both  in  confirming  that  every  requirement  is  covered  and  in 
tracking  the  consequences  of  a change  to  the  system  specification.  Reading 
a column  will  chow  the  partial  (P)  or  coinplete  (C)  satisfaction  of  a system 
requirement  in  the  corresponding  DPSPR  section.  In  the  present  ease,  each 
system  requirement  has  some  DPS  impact ; that  might  not  be  true  in  general. 

For  example,  if  a hard  stop  on  elevation  angle  were  implemented  in  the  radar, 
then  the  third  requirement  under  3.2.2  would  be  deleted , and  the  implementa- 
tion of  the  third  requirement  of  (Paid  I)  1.1. 2. 2 would  be  virtually  completely 
contained  in  the  radar  subsystem. 

3 . 2 Data  Processi no  Subsystem  Px-gui renents 

Many  of  the  following  specific  requirements  are  stated  in  terms  of  a 
value  ana  a probability  of  its  satisfaction.  In  each  such  case,  the  inter- 
pretation shall  be  that  at  every  point  in  the  engagement,  the  probability  of 
satisfying  the  inequality  shall  be  at  least  the  stated  value.  The  required 
confidence  in  that  assertion  is  established  in  test  planning. 

3.2.1  Initial ization 

2 

a)  The  DPS  shall  accept  commands  from  the  C to  initiate  track  on  a 
designated  object.  A radar  order  in  response  to  such  a command 
shall  be  provided  at  the  radar  interface  for  transmission  within 

55  milliseconds  of  the  co;mnand  with  probability  .9.  These  commands 
are  defined  in  Reference  2.4  [TLS  C^/DPS  Interface  Specification]. 

b)  Capacities.  The  DPS  shall  be  able  to  accept  handoffs  at  a rate 
of  150  per  second  over  any  interval  greater  than  50  milliseconds, 
and  a total  of  1500  handoffs  per  engagement,  of  which  up  to  300 
will  be  real  images. 

3.2.2  Termination 


a)  The  DPS  shall  command  not  more  than  15  pulses  to  a redundant  image 
with  probability  .7,  nor  more  than  50  with  probability  .99. 
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b)  The  DPS  shall  command  not  more  than  seven  pulses  to  a ghost  with 
probability  .7. 

c)  The  DPS  shall  command  no  track  pulse  with  elevation  angle  less  than 
3°. 

d)  The  DPS  shall  command  no  track  pulse  to  an  image  of  an  object  which 
has  achieved  an  elevation  of  less  than  5°,  or  which  will  attain 
such  an  elevation  by  the  time  of  transmission,  with  probability  .9. 

e)  For  an  image  on  which  a drop-track  command  is  received,  the  DPS 
shall  command  no  transmission  with  execution  time  more  than  100 
milliseconds  after  appearance  of  the  order  at  the  C2  interface 

with  probability  .7,  nor  more  than  300  milliseconds  with  probability 

.99. 

3.2.3  Tracking 

a)  The  DPS  shall  maintain  an  estimate  of  state  for  each  image  in 
track.  Defining  the  true  state  of  an  image  by  Appendix  A,  estimated 
state  shall  deviate  from  true  state  by  not  more  than  the  tolerance 
of  Figure  A-l  (TBD)  with  the  probabilities  of  that  Figure,  where 
the  assessment  is  relative  to  the  time  of  the  last  processed  return. 

b)  The  probability  that  all  images  of  an  object  shall  be  dropped  as 
redundant  shall  not  exceed  .01. 

c)  The  probability  that  any  image  of  an  object  shall  be  dropped  as 
a ghost  shall  not  exceed  .2. 

d)  The  DPS  shall  command  track  pulses  at  a rate  sufficient  to  keep 
the  propagated  error  defined  by  Appendix  B less  than  the  tolerances 
of  Figure  3-2  (TBD)  with  probabilities  defined  in  that  Figure. 

e)  The  DPS  shall  provide  orders  to  the  radar  in  accordance  with  the 
interface  specification.  The  relevant  fields,  timing,  etc.,  are 
defined  in  [2.3].  In  particular,  the  DPS  shall  select  waveforms, 
frequencies,  beamwidths  and  related  parameters  in  accordance  with 
radar  constraints  in  order  to  satisfy  TLS  performance  requirements. 

f)  The  DPS  shall  accept  radar  returns  in  accordance  with  the  Interface 
Specification  [2.3]. 

g)  The  DPS  shall  maintain  track  on  each  image  until  one  of  the  following 
conditions  is  satisfied: 

1)  Drop  Track  command  received, 

2)  Image  determined  to  be  redundant, 

3)  Image  determined  to  be  a ghost,  or 

4)  Estimated  elevation  of  object  or  of  image  expected  to  violate 
elevation-angle  constraint  before  next  assessment. 
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3.2.4  Resource  Control 


a)  The  DPS  shall  maintain  an  estimate  of  radar  energy  scheduled  by 
track  functions  which  shall  be  within  three  percent  of  the  energy 
nominally  expended,  and  an  upper-bound  estimate  such  that  the 
actual  ERP  and  total  radiated  energy  do  not  exceed  the  bound  with 
probability  (TBD). 

b)  The  DPS  shall  allocate  radar  commands  so  that  not  more  than  (TBD) 

joules  are  commanded  per  image,  nor  more  than  (TBD)  kilowatts  or  (TBD) 
pulses/second  for  all  images  in  track. 

3.2.5  Data  Recording 

The  DPS  shall  output  to  permanent  file  the  following  data: 

a)  Time  of  handoff  and  designation  and  estimate  provided. 

b)  Time  of  termination  of  track  on  each  designation  with  reason 
for  termination.  The  reason  shall  be  one  of  the  following. 

1)  Drop  Track  Command 

2)  Minimum  Elevation 

3)  Image  Declared  Redundant 

4)  Image  Declared  uiiost. 

c)  Subsequent  to  each  state  update,  the  resulting  estimate  of 
state  on  that  image.  Contents  of  that  estimate  are  TBD. 

d)  At  intervals  not  greater  than  300  milliseconds  the  usage  of 
radar  resources.  That  estimate  shall  include  the  nominal 
and  upper  bounds  defined  in  3.2.4,  and  TBD  additional  data. 


4.0  GLOSSARY 
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State  Vector:  A set  of  data  pertaining  to  a specified  image  defining  its 
location  in  space  and  permitting  extrapolation  of  its  location  to 
other  times.  The  contents  of  the  state  vector  may  vary  with  different 
applications;  in  particular,  the  coordinate  system  employed  is  dependent 
on  the  use  to  which  it  will  be  put.  A conventional  state  vector  in 
RFCC  is:  R,  U,  V,  R,  U,  V,  3 \ and  the  time  to  which  all  are 
referenced. 

Object:  A physical  entity  external  to  the  DPS  with  radar  reflection  properties 
corresponding  to  a reentry  vehicle  of  the  defined  threat. 

Image:  A target  defined  to  the  TLS  DPS  for  tracking  and  categorization  as  the 
image  to  be  tracked,  a redundant  image,  or  a ghost. 

Ghost:  An  image  with  which  no  object  is  correlated. 

Redundant  Image:  An  image  which  correlates  with  both  an  object  end  another 
image.  Of  the  set  of  redundant  images  of  an  object,  one  is  intended  to 
be  retained  in  track  while  the  others  are  categorized  as  redundant 
and  dropped. 

Handoff : The  receipt  by  the  TLS  DPS  of  a valid  order  to  initiate  track  on 
an  image. 

Track  Termination:  The  receipt  by  the  TLS  DPS  of  a valid  order  to  Drop 

Track,  or  the  determination  by  the  DPS  that  tracking  should  be  terminated. 
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STATE  VECTOR  PREDICTION 


The  filter  maintains  the  state  vector  in  the  RFCC  system  at  all  times. 
Specific  details  of  the  equations  of  motion  and  the  method  of  trajectory 
integration  employed  for  state  vector  prediction  in  the  RFCC  system  are 
presented  in  this  section.  Figure  8-1  defines  the  RFCC  system. 

1 . 1 Equations  of  Motion 

In  the  general  formulation  of  tiie  equations  of  motion,  it  is  assumed 
that  all  vector  variables  appearing  in  the  differential  equations  are 
appropriately  referenced  to  the  RFCC  system  associated  with  the  face  of  a 
given  radar  under  consideration.  Explicit  expressions  for  the  transformed 
variables  are  given  whenever  they  first  appear. 

Let  the  RFCC  position  vector  to  a target,  denoted  r^,  have  Cartesian 
components  X^.,  and  Z^.  The  differential  equations  describing  the 
motion  of  a target  in  the  rotating  RFCC  system  may,  in  general,  be  written 

as 

UK. 


v - r. 


>V 


(A.  1 ) 


- 2 x i j.  - Wj  x x Rj-) 


and  assuming  constant  A model 

A = 0 


where 


p = GM 

G = universal  gravitational  constant 
M = mass  of  the  earth 

is  the  vector  from  the  yeocenter  to  the  target 

p is  the  atmospheric  density  which  is  a function 
of  the  altitude  h 

g = earth's  sea  level  gravity 

X is  the  inverse  of  the  ballistic  coefficient 
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Figure  A-l  Radar  Face  Centered  Coordinates 


u.p  earth's  angular  rotation  rate,  a vector 
quantity  resolved  along  an  earth-centered 
Cartesian  coordinate  system  aligned  with  the 
RFCC  system. 

Define  as  the  vector  from  the  geocenter  to  the  radar  site  expressed 
in  the  RFCC  system.  Then 

K,  = K • r + 


f s C 


where  the  vector  R is  given  by 


sf 


Re  Cos  E 
H Sir,  K 

I ' 


(A.2) 


(A. 3) 


and  E is  the  elevation  angle  of  the  radar  boresight  with  respect  to  the 
local  horizon  plane. 


Tnfc  earth  rotates  about  the  polar  axis  ‘with  c constant  angular 
ity  w . The  compor 
RFCC  system  is  given  by 


velocity  w . The  components  of  the  earth's  angular  velocity  vector  in  the 
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(A. 4) 


where  A is  the  azimuth  of  the  radar  boresight  with  respect  to  the  radar 
centered  horizon  coordinate  system  and  <j>  is  the  geocentric  latitude  of  the 
radar  site. 


1.2  Trajectory  Integration 

The  trajectory  integration  involved  in  the  prediction  of  the  state 
vector  will  be  perFormed  by  a second-order  Taylor's  scries  expansion  in 
Atn  = tn+j  - t for  the  position  vector  ry  which  gives 
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and  consequently,  the  velocity  vector  is  given  by 


r£(tn+l)  = "f(tn)  + "f(tn)Atn 


(A.  6) 


and 


X<W  = >(tn> 


(A. 7) 


where  rf(tn)  is  readily  evaluated  from  Eq.  (1.1)  by  using  the  current 


estimate  of  the  state  vector  at  t . 

n 
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PROPAGATION  OF  ERRORS 


Ignoring  the  process  noise,  the  propagation  of  the  state  error  covariance 
matrix  from  cycle  to  cycle  is  computed  by 

P (n+l/n)  - *(nfl,n)  r(n)  $T(ivl-l,n)  (B.l) 


in  which  i-(n+l,n)  is  the  state  transition  matrix  expressed  in  terms  of  the 
appropriate  filter  coordinate  system  (RVCC). 

The  derivation  of  the  4>  matrix  starts  with  the  first  order  Taylor's 
expansion  of  a set  of  nonlinear  differential  equations  describing  the  target 
motion  about  some  nominal  solution  of  the  state.  For  this  specific  develop- 
ment, the  target  motion  Eq.  (A.l)  is  approximated  by 


i ..  EcJ 

£ 2 


(B.2) 


that  is,  all  other  accelerating  forces  except  that  due  to  the  atmospheric 
drag  are  ignored. 


The  decoupled  in-plane  and  out-of-plane  transition  matrices  4>p  and 
$n  in  the  RVCC  system  are  given  by 
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APPENDIX  B 


RADAR/DPS  INTERFACE  SPECIFICATION 


1.0  SCOPE 


This  specification  defines  the  physical  and  functional  interface  between 
the  Radar  and  the  Data  Processing  Subsystem  (DPS)  of  the  Track  Loop  System  (TLS). 
The  TLS  itself  is  a testbed  derived  from  a Preliminary  Ballistic  Missile  Defense 
System  (PBMDS),  which  is  in  turn  a representative  but  unreal  environment  for 
these  studies.  TLS  is  intended  to  have  development  and  test  capability, 
although  realization  of  that  capacity  in  actual  testing  is  not  now  contemplated. 

This  specification  corresponds  to  one  which  would  he  available  prior 
to  preparation  of  a PPR.  To  that  end , its  contents  have  been  extracted  from 
TDP  documentation.  Reference  is  made,  to  that  material  as  the  source  from 
which  data  here  labelled  "TBS”  and  "TBD"  will  be  derived.  In  this  publication 
"TBS"  is  used  to  identify  material  expected  to  be  required  during  early  stages 
of  PFR  preparation , while  "TBD"  denotes  material  which  may  be  supplied  later  in 
the  specification  process.  Material  presented  in  italics , such  as  this 
paragraph,  is  illustrative  or  informative  in  nature,  and  would  not  normally 
appear  in  ouch  a specification. 

Some  of  the  paragraphs  in  this  Interface  Specification  place  coyistraints 
or  requirements  on  the  DPS ; these  have  bean  identified  by  a * in  front  of  that 
paragraph. 


B-2 


- 


r 


2.0  applicable;  documents 

2.1  TLS  SYSTFM  REQUIREMENTS  27332-6921-011,  PART  I,  SECTION  1.1 

2.2  TLS  DATA  PROCESSING  SUBSYSTEM  PERFORMANCE  REQUIREMENTS  (DPSPR)  27332- 
6921-011,  PART  II 

2.3  TLS  RADAR  PERFORMANCE  SPECIFICATION 

2.4  TLS  ENVIRONMENT  AND  THREAT  MODEL  DEFINITION 


3.0  INTERFACE  REQUIREMENTS 


3.1  PHYSICAL  INTERFACE 

TBD 

The  physical  interface  is  highly  dependent  on  hardware  selection  for 
both  the  DPS  and  the  Radar ; in  general , it  will  be  irrelevant  to  the  speci- 
fication process  through  the  Preliminary  Design  Review.  Some  portions  of 
the  physical  interface  may  be  specified  during  PPR } notably  those  relating 
to  timing  of  signals  and  clock  protocol. 

3.2  FUNCTIONAL  INTERFACE 

The  functional  interface  between  the  DP  and  the  Radar  shall  consist  of: 
t Commands  issued  by  the  DP  to  the  Radar 

• Returns  issued  by  the  Radar  to  the  DP 

• Engagement  Clock  issued  by  the  Radar  to  the  DP 

3.2.1  Radar  Command  Generation 

a.  The  Radar  will  execute  only  the  commands  issued  by  the  DP. 

* b.  Each  command  shall  contain  transmit,  receive  and  synchronization 
data  as  described  herein. 

c.  The  radar  shall  transmit  one  pulse  for  each  command  which  satisfies 
the  radar  and  interface  constraints.  Within  PBMDS , but  external  to  TLS1 
there  are  exceptions  for  pulse  pairs  and  for  verify  pulses. 

* d.  The  DPS  shall  command  a single  receive  window  for  each  pulse. 

Within  each  receive  window,  the  DPS  shall  command  at  least  one  receive  gate. 

3.2.2  Command  Ordering 

a.  Radar  shall  execute  commands  in  the  order  received. 

* b.  The  DPS  shall  provide  End  of  Transmission  at  least  1 msec  before 
the  scheduled  execution  time  of  the  first  command  in  the  message. 

3.2.3  Command  Unpacking  and  Decodi ng 

* The  DPS  shall  issue  commands  in  accordance  with  the  format  of  TBD. 
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3.2.4  Timing  Control 


' a.  The  commanded  times  for  Radar  actions  or  for  returns  shall  be  in 
absolute  time  measured  from  a clock  with  nominal  1.68  second  rollover.  The 
least  significant  time  bit  shall  be  6.25  nsec. 

b.  Radar  shall  determine  all  intermediate  times  needed  to  comply  with 
command  data  for  transmission  and  reception. 

c.  The  DPS  shall  not  command  receive  windows  which  overlap.  The 
receive  window  duration  in  each  case  shall  be  at  least  the  uncompressed  pulse 
length  plus  the  desired  range  coverage. 

d.  The  DPS  shall  not  command  conflicting  transmissions.  Consecutive 
commands  shall  be  separated  in  execution  time  by  at  least  the  uncompressed 
pulse  length  of  the  earlier  plus  TBS. 

3.2.5  Command  Contents 

a.  The  DPS  shall  provide  a waveform  identifier  corresponding  to  one  of 
the  waveforms  of  Table  A. 2 (TBD)  in  each  command. 

b.  The  DPS  shall  provide  in  each  command  both  transmit  and  receive  codes 
corresponding  to  direction  cosine  phase  tapers. 

c.  The  DPS  shall  provide  a receiver  gain  setting  in  each  receive  window. 

d.  The  DPS  shall  provide  a signal  processing  mode  code  in  each  receive 

gate. 

e.  The  DPS  shall  provide  a fixed  signal  acceptance  threshold  and  threshold 
type  selection  for  each  receive  gate. 

f.  The  DPS  shall  provide  the  range  gate  mark  generation  technique  for 
each  receive  gate. 

g.  The  DPS  shall  provide  the  transmit  power  level  for  each  command. 

3.2.6  Return  Contents 

a.  Radar  shall  return  identifier  data  provided  in  the  command. 

b.  Radar  shall  return  actual  range  mark  times  and  the  signal  amplitude 

at  each  range  mark. 

c.  Radar  shall  return  video  signal  amplitudes  at  conmanded  points. 

Amplitude  shall  be  corrected  by  the  Radar  for  stored  instrumental  errors. 
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d.  For  appropriate  commanded  signal -processing  modes  and  waveforms, 
the  Radar  shall  return  direction  cosines  of  the  echo.  Directional  data  shall 
be  corrected  by  the  Radar  for  stored  instrumental  errors. 

e.  For  appropriate  commands,  the  Radar  shall  return  TBS  wake  array  data. 

f.  Radar  shall  return  noise  level  relevant  to  each  amplitude  in  a return. 

3.2.7  Error  Hand! ing 

a.  Radar  shall  return  an  error  message  for  each  discernible  command  not 
implemented.  That  message  shall  include  a code  corresponding  to  the  reason 
for  the  failure  of  transmission.  Among  the  reasons  may  be  preemption,  receive 
or  transmit  window  overlap,  insufficient  time  for  transmission,  and  faulty 
command  (internal  inconsistency). 

* b.  The  DPS  shall  initiate  a record  on  permanent  file  of  each  error  return. 

* c.  The  DPS  shall  determine  whether  the  fault  is  persistent  or  unique; 

if  persistent,  whether  it  is  safety-related.  (Definitions  TBS).  A persistent, 
safety-related  fault  shall  cause  test  termination  to  be  commanded  by  the  DPS 
within  TBS  milliseconds;  in  particular,  no  command  shall  be  issued  for  trans- 
mission by  the  Radar  more  than  TBD  milliseconds  after  a persistent,  safety- 
related  fault  is  detectable  from  returns. 

3.2.8  Mode  Change 

The  DPS  shall  control  all  Radar  mode  changes  through  issuance  of 
appropriate  commands.  The  changes  shall  include  startup  and  shutdov/n.  Time- 
line constraints  on  mode  changes  and  on  preparation  time  for  transmission  are  TBS. 

3.2.9  Timing 

a.  Radar  shall  provide  a master  timing  reference  to  DPS  via  TBS  interface. 

b.  The  clock  shall  provide  28  bits  of  data  with  a least  significant  bit 
of  6.25  nsec. 

c.  The  resetting  of  the  clock  shall  be  entirely  under  Radar  control.  In 
consequence,  its  absolute  value  shall  be  regarded  by  the  DPS  as  arbitrary.  The 
Radar  shall  reset  the  clock  within  TBS  milliseconds  of  startup,  and  shall  not 
again  reset  it  during  the  engagement. 
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3.2.10  Miscellaneous  Requirements 


a.  Negative  numbers  crossing  the  interface  shall  be  represented  in 
two's  complement  form. 

b.  Radar  coordinates  shall  be  defined  in  accordance  with  Figure  3-1. 
3.3  DATA  REQUIREMENTS  AND  FORMATS 

TBS 

Data  requirements  and  formats  have  been  defined  for  TOP,  and  that 
definition  might  be  carried  over  to  the  present  document.  However,  it  is 
not  characteristic  of  systems  such  as  TLS  that  details  of  bit  positions , 
message  formats,  etc.,  would  be  known  at  this  stage  of  development.  However, 
the  dynamic  range,  units , and  least  significant  bit  information  is  necessary 
in  order  to  write  performance  requirements  on  radar  command  generation.  The 
formats  identification  can  be  postponed  until  process  design  time. 
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Figure  3-1.  Radar  Coordinate  System 
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APPENDIX  C 

C2/DPS  INTERFACE  SPECIFICATION 


1.0  SCOPE 


This  specification  defines  the  physical  and  functional  interface  between 

2 

the  Command  and  Communications  (C  ) System  and  the  Data  Processing  Subsystem 
(DPS)  of  the  Track  Loop  System  (TLS).  The  TLS  itself  is  a testbed  derived 
from  a Preliminary  Ballistic  Missile  Defense  System  (PBMDS),  which  is  in  turn 
a representative  but  unreal  environment  for  these  studies.  TLS  is  intended 
to  have  development  and  test  capability,  although  realization  of  that 
capacity  in  actual  testing  is  not  now  contemplated. 

This  specification  corresponds  to  one  which  would  be  available  prior  to 
preparation  of  a PPR.  To  that  end , its  contents  have  been  extracted  from  TDP 
documentation.  Reference  is  made  to  that  material  as  the  source  from  which 
data  here  labeled  "TBS”  and  "TBD"  will  be  derived.  In  this  publication , "TBS" 
is  used  to  identify  material  expected  to  be  required  during  early  stages  of 
PPR  preparation , while  "TBD"  denotes  material  which  may  be  supplied  later  in 
the  specification  process.  Material  presented  in  italics , such  as  this 
paragraph,  is  illustrative  or  informative  in  nature,  arid  would  not  normally 
appear  in  such  a specification. 

Some  of  the  paragraphs  in  this  Interface  Specification  place  constraints 
or  requirements  on  the  DPS ; these  have  been  identified  by  a * in  front  of 
that  paragraph. 
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3.0  INTERFACE  REQUIREMENTS 


3.1  PHYSICAL  INTERFACE 

TBD 

The  physical  interface  between  the  C2  and  the  DPS  is  entirely  dependent 
on  hardware  selection.  It  will  define  polarity  conventions , signal  levels , 
and  related  parameters  of  interest  only  following  PDRa  and  accountable  only 
from  the  time  of  hardware  integration.  Although  this  section  is  required  in 
such  an  interface  specification , it  will  normally  remain  undetermined  throughout 
the  early  stages  of  software  design. 

3.2  FUNCTIONAL  INTERFACE 

p 

The  functional  interface  between  the  C and  the  DPS  shall  consist  of 

2 

messages  of  four  types  transmitted  from  the  C to  the  DPS. 

• Initiate  Engagement  Mode 
e Terminate  Engagement  Mode 

• Handover  Image 

• Drop  Image  Track 

3.2.1  Initiate  Engagement  Mode 

a.  The  DPS  shall  accept  an  Initiate  Engagement  Mode  message  from  any  of 
the  following  prior  modes  of  the  DPS:  TBD. 

b.  The  DPS  shall  be  prepared  to  accept  a Handover  Image  message  within 
TBS  seconds  of  appearance  of  the  Initiate  Engagement  Mode  message  at  the 
interface. 

3.2.2  Terminate  Engagement  Mode 

★ 

a.  The  DPS  shall  accept  a Terminate  Engagement  Mode  message  at  any 
time  when  it  is  in  Engagement  Mode.  The  DPS  shall  transition  to  TBD  mode  in 

response  to  a Terminate  Engagement  Mode  message. 

★ 

b.  The  DPS  shall  command  no  Radar  transmission  with  an  execution  time 
more  than  TBS  milliseconds  following  appearance  of  a Terminate  Engagement  Mode 
message  at  the  interface. 


3.2.3  Handover  linage 

a.  The  contents  of  the  Handover  Image  message  shall  be 

Image  designation 
Image  estimated  state 
TBS 
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b.  The  C shall  transmit  no  Handover  Image  message  except  when  the  DPS 
has  been  placed  in  the  Engagement  Mode  by  transmission  of  an  Initiate  Engage- 
ment Mode  message  at  least  TBS  milliseconds  earlier,  and  since  the  last 
Terminate  Engagement  Mode  message. 

3 . 2 . 4 Drop  Image  Track 

a.  The  contents  of  the  Drop  Image  Track  message  shall  be  the  image 
designator. 
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b.  The  C shall  transmit  no  Drop  Image  Track  message  for  an  image  designator 
unless  that  designator  was  previously  included  in  a Handover  Image  message. 

3.2.5  Message  Acknowledgement 

TBS 

3.2.6  Error  Handl ing 
TBS 

3.3  DATA  REQUIREMENTS  AND  FORMATS 
TBD 

Data  requirements  and  formats  have  been  defined  for  TDP,  and  that 
definition  might  be  carried  over  to  the  present  document.  It  is  not 
characteristic  of  systems  such  as  TLS  that  details  of  bit  positions , message 
formats,  etc.,  would  be  known  at  this  stage  of  development.  However,  the 
dynamic  range,  units,  and  least  significant  bit  information  is  necessary 
in  order  to  write  performance  requirements  on  the  radar  command  generation. 

The  formats  identification  can  be  postponed  until  process  design  time. 
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RSL  TERMINOLOGY 
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ELEMENT.TVPE  I 
STRUCTURE 


1 

ALPHA 

(*  A PROCESSING  STEP  IN  THE  FUNCTIONAL  REQUIREMENTS 
DOMAIN,  *), 

APPLICABILITY!  NET, 
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DATA 

(*  A SINGLE  HE.H  OR  SET  OF  PATA  that  is  SPtCIFlEO 
AND  THAT  NIlL  EIThER  BE  REQUIRED  I*  THE 
REAL-TIHE  SOFTWARE  OR  IS  NEEDEQ  For 

descriptive  purposes.  *). 


ELEHENT.TYPE I 

J 


ELEMENT.TVPf  I DECISION 

(*  THE  DECISION  THAT  has  BEEN  MADE  TO  ENABLE 

REQUIREMENTS  TO  Be  TAKEN  EROM  The  dpspr  to  the  ppr, 
THIS  MEANS  that  The  REQUIREMENTS  ARE  NOT  SImPUT 
ALLOCATED,  but  HAvE  BEEN  SUBJECTED  TO 
DERIVATION,  a). 


ELE^ENT.TVPFJ  ENT  I TY„Cl ASS 

c*  a general  class  flF  "objects"  in  the  real  world 

OUTSIDE  the  Cata  PROCESSING  SYSTEH  AND  *WICh  IS 
IMPORTANT  To  it,  FOR  example,  an  ENTITY.CLaSS 
might  be  rvs  or  interceptors,  the  entity_types 

MIGHT  BE  DETECTION,  POTENT T AL_RV , I DENT  IF IEQ.R V , 
ETC,  *). 
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ELEHENT.TYPC  I £NTITY_TYPE 

' (*  A SPECIFIC  TYPE  OF  "OBJECT"  IN  THE  HEAL  WORLD 

OUTSIDE  THE  DATA  PROCESSING  SYSTEM  AND  *HICh  IS  «F 
IMPORTANCE  T<?  IT.  WHEN  A SPECIFIC  TYPE  OF  "OBJECT" 
IS  determined  TO  exis,  IN  An  entity.class.  files 

and  OATA  may  BE  TEMPORARILY  CREATED  TO  MAINTAIN 
INFORMATION  about  IT. 


ELEMENT.TYPEJ  event 

(*  AN  IDENTIFIED  PPInT  THAT  EXISTS  IN  THE  PROCESSING 

of  one  o w more  r.nEts  or  subnets  an:  which  may 

CAUSE  THE  EnASLEmEnT  OP  AM  R_nFT,  * ) , 

STRUCTURE  APPLICABILITY  | hfr, 

STRUCTURE  APPLICABILITY!  PATH, 


ELEMENT„TYPEI  FILE 

(*  AN  AGGREGATION  (JF  INSTANCES  OF  DATA,  EACH  INSTANCE 
OF  WHICH  IS  TREATED  IN  THE  SAME  MANNER,  •), 
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element„.typei  input.interface 

(*  A "PART"  BETWEEN  the  DATA  PROCESSING  SYSTEM 
ANO  THE  REST  OF  ThE  BMD  SYSTEM  WHICH  ACCEPT* 
DATA  FROM  THE  OTHER  SYSTEM  CE.G,  THE 
RAOAP.RETURnS),  *), 

STRUCTURE  APPLICABILITY!  NET  „ 


r 


ELEMfcNT_TYPEl  MESSAGE 

(*  AN  AGGREGATION  (IF  DATA  AND  FILES 

that  pass  Through  an  intfrface  as  a logical 

UNIT.  *). 
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ELEMENT^ T VPf  | eRIGIN»TlNG.»Er.uiPEMEM 

(*  THE  HIGHER  LEVEL  (OPSPR)  REQUIREMENT  PROP  *hICH 
LOkER  LEVEL  REQUIREMENTS  (ThE  OnES  DESCRIBED  IN 
THE  RSL)  ARE  TRACEABLE,  *), 


D-l  1 


ELEMENT.TYPEI  PUTPUT.INTERFaCE 

(*  A "PORT " HE  T^EES  THE  DATA  PR  "CF  SS  I Sti 

ANO  THE  RESt  r»F  fHf  bhd  system  which 
OATa  Tfl  THE  OTHER  SYSTEM  Ct.G,  ThE 
RAOAR.COMMAnCS).  *). 

STRUCTURE  APPL IC AR I L I T V J SET 


SYSTEM 
T R AS $M  j TS 
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ELEMENT. TYPE  I PERFORM ANCE.REGU I REmE NT 

(*  AN  ANALYTIC  PERFORMANCE  REQUIREMENT  OR 
NON-STlM'JLUS*RESPONSr  TIMING  REQUIREMENT 
RHICH  IS  TO  PE  MET  BY  THF  REAL-TIME  SOFTMRe,  *). 
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ELEMENT.TYPEI  r.net 

(*  The  ORDER  OF  LOGICAL  PROCESSING  $TfPS  THAT  MuST  8E 
PERFORMED,  AN  R_N£  T may  CONTAIN  AnDS,  ORS#  AND 
FOR  EACH  NODES;  Jt  H(jST  3E  ENAHLEO  AND  TERHInATED, 
The  PROCESSING  STFpS  ARE  ALPHAS  OR  SUBNETS  WHICH 
may  be  EXPANDED  into  LOWER  LEVELS  OF  DETAIL,  AN 
R_NET  hAy  ALs?  CONTAIN  VAl  irATIoN_poiNTS/  EVENTS# 
AND  INTERFACES,  a). 
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ELEMEM.TYPEl  SOURCE 

(*  SOURCE  MATERIAL  For  REQUIREMENTS.  i.e.»  ORIGINATING 
point  FOR  One  or  more  ORIGINAT InG.REQUIKEMEnTS# 
DOCUMENTATION  or  TRADE-OFF  STUDIES#  OR  ttACKGROUND 
MATERIAL  for  REDIIREMENTS  FLEmFnTs,  *), 


ELEHtNT.TVPC 


structure 


SUBNET 

(*  THE  ORDER  PE  LOGICAL  PROCESSING  STECS  THAT  M|jST  BE 
PERFORMED  In  ORDER  TO  PERFORM  the  FEuUIRtMENTS  OF 
THE  PROCESSING  STEP  T M A T REPRESENTS  IT  AT  THE  NEXT 
HIGHER  LEVEL.  *), 

APPLICABILITY!  E E T , 
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ELE^ENT.TYPEI  SUBSYSTEM 

(*  A PART  3F  THE  PMD  SySTEH  (SUCH  As  RADAR)  WHICH 

communicates  with  the  data  processing  system  *3, 
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ELEMENT-TYPE  I SYNONYM 

(*  A SYNONYM  Is  mfrEly  an  alternate  name  THAT 
CAN  PE  USED  IN  dLaCE  OF  THE  PRIME  name,  IT 
IS  USED  AS  an  APBrEVIATIpin  IN  M 0 S T CASES» 
HUT  may  be  uSFD  For  OTHER  »LAs"nS  Also, 
NOTEI  IN  A n <ELEMENT  TYPE  L I S Y > , "ALL* 
ALWAYS  IMPLIES  "ALL  EXCEPT  synonym",  *), 
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EIEMENT..TVPEI  UNSTRUCrU«ED_ttfc  QUIRE MEM 

'(*  A REQUIREMENT  THiT  MUST  3F  PASSED  T 0 THE  DESIGNER  0F 
THE  REAL-TIME  CPDE  BUT  THAT  DOES  NO T FIT  INTO  THE 
STRUCTURED  Framework  PROVIDFD  BY  r$l,  THIS  Et-EMENy 
MIGHT  BE  USED  BECAUSE  THE  REQUIREMENT  IN  QUESTION  IS 
TOO  UNIQUE  Tg  JUSTIFY  DEFINITION  OF  A N£w  TYRE  OF 

element*  A new  relationship*  OR  a new  attribute,  IT 
ALSO  MIGHT  BE  USED  BECAUSE  THE  REQUIREMENTS  ANALYST 
DOES  NOT  CARE  to  DESIGN  A NEw  CONCEPT  TO  FIT  THE 

requirement*  or  because  the  requirement  is  clearly 

A DESIGN  limitation  THAT  SHOULD  BE  OESCRIBEO 
IN  ENGLISH  Text.  (AN  EXAMPLE  of  the  last 
REASON  MIGHT  BE  PRECLUSION  OF  USING  A 
MULTIPROCESSOR  wjTh  ASSOCIATIVE  MEMORY,)  *), 
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ELEHENT.TVPFI  VALIDATI1n_PAtH 

(*  THE  PATH  OF  PROCESSING  «VEW  whjch  the  QUANTITATIVE 

VALIDATION  Tt  S T I kjG  WILL  ?E  PEPfrtRMf  D,  *), 


ELEVEN T„TYPEl  V AL in  AT  I ON_P fl IN T 

(*  a logical  point  is  the  processing  at  khjch  timing# 
value#  OR  PRESENCE  DATA  must  re.  OBTAINABLE  In  the 
PEAL-TIME  SOpTwAPE  IN  flPOpR  TO  VALIDATE  THAT  THE 

requirements  have  qeen  fulfilled,  *) . 

STRUCTURE  APPLICABILITY:  net, 

STRUCTURE  APPLICABILITY:  PATH, 
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ELEMENT.TVPP  I VERSION 

(*  THE  AGGREGATION  OF  R£QUI«FMFNTs  THAT  ARE  TO 
APPLY  AS  A Unit  Tfl  THE  data  PROFESSING 
SYSTEM  at  a PARTICULAR  time.  LOQP.l, 

LOOP_2>  ETC,,  are  VERSIONS,  AS  Is  AN  IOC 
SYSTEM,  *), 

RELATIONSHIP!  ASSOCIATES 

(*  TELLS  WHICH  data  AND  FILES 

come  into  existence  when  the  data 
PROCESSING  system  (SOME  ALPHA)  CREATES  AN 
INSTANCE  OF  an  FNtITY_CLASS  or  an  R_NET  is 
enabled , *). 

COMPLEMENTARY  RELATIONSHIP!  ASSOCIATED  ("WITH"), 

SUBJECT  ELEMENT_TYPEI  ENT  I T y_Cl ASS 

entity  Type, 

OBJECT  ELEHENT_TYPEi  DATa 

file, 

RELATIONSHIP!  COMPOSES 

(*  TELLS  WHICH  EnttTy. TYPES  ARE  mF.mBFRS  OF  AN 
ENT.TT  Y. CLASS,  *), 

COMPLEMENTARY  RELATIONSHIP!  COMPOSED  ("«F"), 

SUBJECT  ELEMENT_TYPEI  ENtITY  TyPE, 

OBJECT  ELEMENT.TYPE!  EN T i T Y.CL ASS , 

RELATIONSHIP!  CONNECTS  ("TO") 

(*  TELLS  which  SUBSYSTEM  THE  INPuT_INTERFACE  OR 
OUTPUT. INTErF  ace  COMMUNICATES  with.  *), 
COMPLEMENTARY  relationship:  CONNECTED  ("TO"), 

SUBJECT  ELEMENT.TYPE!  I NpL T_ I N t ERF  ACE 

OUTPUT  InTERFACF. 

OBJECT  ELEMENT. TYPE  I SUBSYSTEM, 

RELATIONSHIP!  CONSTRAINS 

(*  IDENTIFIES  TO  WHlCw  VALIDATION. PATH(S)  THE 
PEPFORMANCE^REOUIrEmENT  APPLIES,  *), 

COMPLEMENTARY  RELATIONSHIP!  CONSTRAINED  ("BY"). 

SUBJECT  ELEMENT_TYPEI  PErF  ORmAnCE.RE  aiiJPEMENT  , 

OBJECT  ELEMENT.TYPEl  V AL I C AT  I On.P * TH , 

RELATIONSHIP!  CONTAINS 

(*  tells  the  identity  of  each  constituent  part  of  each 
instance  in  a file,  a direct  implementation  in 

SOFTWARE  WOULD  USE  THIS  RELATIONSHIP  TO  GIVE  THE 
MAKE-UP  OF  RECORDS  IN  FILES,  *), 


| 
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COMPLEMENTARY  RELATIONSHIP » CONTAINED  ("IN"), 

SUBJECT  UEMEN7_TyPEI  FILE, 

OBJECT  ELEMENT.TYPEl  OATa, 

RELATIONSHIP!  CREATES 

(*  TELLS  HHICH  PROCESSING  STEPS  C»EATE  THE  INSTANCE 
OF  AN  ENTITy.CLASS.  *), 

COMPLEMENTARY  RELATIONSHIP!  CREATED  ("BY"), 

SUBJECT  ELEMENT.TyPE I ALPHA, 

OBJECT  ELEM£NT_T YPE l E N T I T V_CL ASS , 

RELATIONSHIP!  DELAYS 

(*  THE  ENABLEMENT  nF  R_NETS  by  ThE  OBJECT  EVENT  IS 
POSTPONED  F 0R  ThE  amount  OF  Time  SPECIFIED  BT 
THE  OATA,  *), 

COMPLEMENTARY  RELATIONSHIP!  DELAYED  ("BY"), 

SUBJECT  ELEHENT.TyPE!  DATA, 

OBJECT  ELEMENT.TTPEl  EvEnT, 

RELATIONSHIP!  DESTROYS 

(*  TELLS  WHICH  PROCESSING  STEPS  DESTROY  AN 
INSTANCE  of  The  ENTITY.CLASS,  *). 

COMPLEMENTARY  RELATIONSHIP!  DESTROYED  ("BY"), 

SUBJECT  ELEMENT.TYPEI  ALPHA, 

OBJECT  ELEMENT.TYPEl  EN T I T Y_CL ASS , 

RELATIONSHIP!  DOCUMENTS 

(*  THE  SUBJECT  SOURCE  MATERIAL  DOCUMENTS  THE  OBJECT 
ELEMENTS,  *), 

COMPLEMENTARY  RELATIONSHIP!  DOCUMENTED  ("By"), 

SUBJECT  ELEMENT.TyPEI  SOURCE, 

OBJECT  ELEMENT.TYPE I Alpha 

data 

DECISION 
ENTI T Y_CLaSS 
Entity  type 
event 

file 

INPUT— INTERFACE 

message 

originatIn  g„ requirement 

OUTPLT^INTERF ace 

PE«FfRMANcE„REDUIREMENT 

R_N£T 

subnet 

SUBSYSTEM 

UnSTRUCTURED.REQUIREMENT 

VALICATI0N«PATH 

valication.point 

VERSION. 
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RELATIONSHIP!  ENABLES 

(*  WHEN  THE  EVENT (s)  IS  (ARE)  PASSED  THROUGH  ey  The 

control  flow  on  an  r.net,  or  when  data  are 
available  at  an  interface  (as  defined  in  the 

INTERFACE  DEFINITION),  the  FUNCTIONAL  PROCESSING 
INDICATED  On  the  R.nET  CAN  BE  BEGUN,  «), 
COMPLEMENTARY  RELATIONSHIP!  ENABLED  ("BY"). 

SUBJECT  ELEMENT„TYpEl  E V£K  T 

input.interface, 
object  element.typei  r.net, 

RELATIONSHIP!  EQUATES  ("TO") 

(*  defines  an  alternate  NAM£  FOR  An  element,  the 
OBJECT  IS  CALLED  THE  PRIme  name,  ThE  SUBJECT  name 
CAN  BE  USED  FOR  InPUT  TO  THE  ASSM,  BUT  ALL 
RELATIONSHIPS,  ATTRIBUTES,  and  STRUCTURES  As 
DEFINED  ARE  ACTUALLY  CHARACTERISTICS  OF  THE  PRIME 
NAME,  *), 

COMPLEMENTARY  RELATIONSHIP!  EGUATED  ("TO"). 

SUBJECT  ELEMENT. TYRE!  SYnOnym, 

OBJECT  ELEMENT.TYPEl  ALPHA 

data 

DECISION 
ENTJT Y.CLASS 
Entity_TyPe 

EVENT 

FILE 

INPuT.inTeRFACE 

message 

ORIgInatInG.REQUIRFmEnT 

OUTpLT.lNTEMFACE 

PERFORM A ncE.REQUTRFmFnT 

R.N£T 

SOURCE 

SUBNET 

SUBSYSTEM 

UNS T R Ur TUrFD.RE QUIRE MEN T 

VALICATION.PATH 

valication.point 

version. 
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RELATIONSHIP!  FORMS 

(a  INDICATES  ThE  AlPhA  whICh  DEFINES  A MESSAGE 
TO  BE  PASSED  THROUGH  AN  OUTPUT,.  INTERFACE,  *), 
COMPLEMENTARY  RELATIONSHIP!  FORCED  ("PY"), 

SUBJECT  ELEMENT.TYPEI  AlpHA, 

OBJECT  ELEMENT^TYPEl  MESSAGE. 

RELATIONSHIP!  IMPLEMENTS 

(•  TELLS  ThE  VERSIONS  TO  WHIC*  ThE  ELEMENT . AS 

described,  applies.  *). 

COMPLEMENTARY  RELATIONSHIP!  IMPLEMENTED  ("BY"), 

SUBJECT  ELEMENT.. TYPE  « ALPHA 

data 

DECISION 
ENtITy_ClASS 
ENtITv  TypE 
EVENT 

EIlE 

INPLT_iNt£RPACE 

message 

ORiGInaT in G— REQUIREMENT 

OUTPUT.InTERFACF 

PErPORmAkCE*REQUIREmENT 

R-nFt 

SUBNET 

subsystem 

UNSTRUCTURED..  REQUIREMENT 
VAlIOATION.PATM 
VA^IDATl On— POINT , 

OBJECT  ELEMENT.TYPEI  VERSION, 

RELATIONSHIP!  INCLUDES 

(*  INDICATES  ThE  HIERARCHICAL  RELATIONSHIP  BETWEEN 
DATA,  IF  A INCLUDES  B#  THEN  OBTAINING  A wIlL 
OBTAIN  8 , *), 

COMPLEMENTARY  RELATIONSHIP!  INCLUDED  ("IN"), 

SUBJECT  ELEMENT^TYPEI  DAtA, 

OBJECT  ELEMENT.TYPEl  DATA. 

RELATIONSHIP!  INCORPORATES 

(A  INDICATES  That  the  SCOPE  OF  THE  SUBJECT  (HIGHER 
LEVEL)  ORIGINATING.REQUIREMENT  INCLUDES  THE 
OBJECT  (LOWER  LFVeL)  OR IG I N AT  I NG.REOUI RtMENy  , *), 
COMPLEMENTARY  PEL AT  I ONSM I p ! INCORPORATED  ("IN"). 

SUBJECT  ELEMENT.TTPEI  ORlG INaT iNG.HEQuIREmeNt , 

OBJECT  ElEMENT.TYPE | ORIgInatInG.REQUIREMFNT, 
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RELATIONSHIP!  INPUTS 

(*  indicates  that  the  named  element  inputs  the 
ABJECT  ELEMENT ($ ) , O, 

COMPLEMENTARY  RELATIONSHIP!  INPUT  CTO"), 

SUBJECT  ELEMENT.TYPEI  ALPHA, 

OBJECT  ELEMENT.TYPEl  DAT  a 

file. 

RELATIONSHIP!  MAXES 

c*  tells  the  identity  of  data  and  files  that 
make  UP  a MESSAGE,  O, 

COMPLEMENTARY  RELATIONSHIP!  mAdE  ("BY"), 

SUBJECT  ELEMENT_TYPEI  DATA 

PlLt. 

OBJECT  ELEMENT.TYPEl  MESSAGE. 

RELATIONSHIP!  ORDERS 

(*  THE  ELEMENT  On  WHICH  THE  INSTANCES  ARE 
ORDERED  in  a file,  *), 

COMPLEMENTARY  RELATIONSHIP!  oRpF.RED  ( "BY " ) , 

SUBJECT  ELEMENT.TYPEI  DATA, 

OBJECT  ELEMENT.TYPEl  FILE. 

RELATIONSHIP!  OUTPUTS 

t*  indicates  The  named  element  outputs  the 

OBJECT  ELEMENT(S),  *), 

COMPLEMENTARY  RELATIONSHIP!  OUTPUT  ("FROM"), 

SUBJECT  ELEMENT_TYPEI  ALPHA, 

OBJECT  ElEMENT.TYPEl  DATA 

FILE. 

RELATIONSHIP!  PASSES 

(*  INDICATES  ThE  INFORMATION  WHICH  PASSES  THROUGH 
THE  INTERFACE,  *), 

COMPLEMENTARY  RELATIONSHIP!  PASSED  ("THROUGH"), 

SUBJECT  ELEMENT^ TYPE  I iNplT.lNyERFACE 

OUTPUT.InTERFACE, 

OBJECT  ELEMENT.TYPEl  MESSAGE, 

RELATIONSHIP!  RECORDS 

(*  INDICATES  That  the  named  VALlDATlON_POINT  RECORDS 
THE  OBJECT  ELEMENTS,  *), 

COMPLEMENTARY  RELATIONSHIP!  RECORDED  ("BY"), 

SUBJECT  ELEMENT.TYPEI  V AL I D AT  I flN.PO I NT , 

OBJECT  ELEMENT.TYPE!  DATa 

file. 

RELATIONSHIP!  SETS 

(*  TELLS  WHICH  ALPHA  SETS  The  ENTlTY.TYPE  OF  An 
INSTANCE  in  An  entITY.CLASS,  »), 

COMPLEMENTARY  RELATIONSHIP!  sET  ("BY"), 

SUBJECT  ELEMENT.YyPEI  ALPHA, 

OBJECT  ELEMENT.TYPEl  ENT  I T Y_T YpE , 


D-26 


RELATIONSHIP!  TRACES  ("TO") 

<*  tells  the  higher  level  (originating)  re&lire*ent 

FROM  WHICH  THE  FLEmENT  WAS  TRACED  (ALLOCATED), 

a default  originating  requirement  is  "none", 
which  indicates  That  THE  element  is  derived, 

WE  WOULD  EXPECT  ThAT  THE  ATTRIBUTE 
"ARTIFICIALITY"  would  have  value 
"ARTIFICIAL"  IF  The  ELEMENT  IS  TRACED  FROM 
"NONE",  HOWEVER*  THIS  MAY  BE  UNTRUE  IN 
CASES  WHERE  An  ARBITRARY  HEURISTIC  MUST  BE 
EMPLSYEO,  *), 

COMPLEMENTARY  RELATIONSHIP!  TRACED  ("FROM"), 

SUBJECT  ELEMENT.TYPEI  DECISION 

0RIGINATING„REQUIREMENT, 

OBJECT  ELEMENT.TYPEl  ALPhA 

data 

DECISION 
ENT  I T Y_CL ASS 
Entity  type 
event 

file 

INPuT^InTeRFACE 

MESSAGE 

outplt.interface 

PERFGRMANCE..REQUTREMENT 

R-NeT 

SUBNET 

SUBSYSTEM 

UNStRUCTUrED.REQUIREMENT 

VALICATION.PATH 

valiCation_point 

VERSION, 

ATTRIBUTE!  ALTERNATIVES 

(*  THE  ALTERNATIVES  THAT  HAVE  BFEN  ENVISIONED  TO 
RESOLVE  THE  PROBLEM.  *), 

APPLICABLE  ELEMENT.TYPE I DECISION, 

VALUE!  TEXT, 
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ATTRIBUTE  1 ARTIFICIALITY. 

APPLICABLE  ELEMENT.TYPEI  alpha 

Data 

decision 
entity.class 
entity. type 
event 
PILE 

INPI)T_INTERFACE 

message 

ORIGIN AT ING.REOUIREmEKT 

OUTPUT-INTERFACE 

performance.requirement 

R-NFT 

SOURCE 

subnet 

subsystem 

UNSTRuCTURED.REQUIREMENT 

VALIDaTION.PATH 

VALIDaTION.POINT 

VERSION, 

VALUE!  ARTIFICIAL 

(*  THc  ELEMENT  mas  Been  DEFINED  for  EXPLANATORY  or 
EXECUTABILItY  PURPOSES  in  THE  REQUIREMENTS 
STATEMENT  AnC  NEED  NOT  BE  PRESENT  IN  THE  REaL-TIME 
SOFTWARE,  *), 

VALUEl  validation 

(a  THE  ELEMENT  IS  NECESSARY  FOR  DESCRIBING 
PERFORMANCE  REQUIREMENTS  BUT  IS  NOT 
REQUIRED  in  THE  REAL-TIME  software,  *), 

VALUEl  IMPLEMENT-APPROXIMaTELY 

(a  THE  ELEMENT  MUST  BE  IMPLEMENTED  IN  THE  REAL-TIME 
SOFTWARE#  But  the  PRECISE  IMPLEMENTATION  is  left  t< 
THE  PROCESS  DESIGNER,  OF  COURSE#  THE  DETAILED 
IMPLEMENTATION  must  be  VALIDATED  by  the 
REQUIREMENTS  ANALYST,  *), 

VALUEl  IMPLEMENT.PRECISELY 

(*  THE  ELEMENT  must  BE  IMPLEMENTED  IN  THE  REAL-TIME 
SOFTWARE  EXACTLY  as  DEFINEDI  NO  CHANGES  SHOULD  BE 
CONSIDERED  UNTIL  PERMISSION  IS  OBTAINED  from  the 
REQUIREMENTS  ANALYST,  *), 

ATTRIBUTE!  BETA 

(a  THIS  PROVIDES  THE  PROCEDURAL  CODE  (WHICH  IS  NOT 
INTERPRETED  BY  THE  RSL  PROCESSORS)  FOR  FUNCTIONAL 
MODELS,  IT  IS  PASSED  TO  THE  SIMULATION  GENERATOR 
AND,  SUBSEQUENTLY,  TO  THE  COMPILER,  a), 

APPLICABLE  ELEMENT.TYOEi  alpha, 

VALUEl  TEXT, 
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ATTRIBUTE!  CHOICE 

(*  THE  DECISION  PROW  among  THE 
rationale  for  the  decision, 
applicable  element* TYPE  I DECISION, 

VALUE!  TEXT, 


ALTERNATIVES  kith  the 

*). 


ATTRIBUTE!  COMPLETENESS, 

APPLICABLE  ELEMENT.TYPEi  alpha 

data 

decision 

entity.class 

ENTITy„TYPE 

Event 

file 

!NPtlT_lNTERFACE 

message 

ORIGIN AT ING.REDUIREmENT 

OUTPUT-INTERFACE 

perfor^ance.requirement 

R_net 

SOURCE 

Subnet 

Subsystem 

unstRuctured.requirement 

valiDation.path 

VALIDaTION.POINT 

VERSION, 

VALUE!  INCOMPLETE 

(*  THE  ELCMENTIS  DESCRIPTION  IS  KNOWN  TO  BE 

INCOMPLETE,  THEREFORE#  READERS  SHOULO  BE  AhARE 
THAT#  EVEN  IF  ALL  RELATIONSHIPS,  ATTRIBUTES,  AND 
STRUCTURES  ARE  STATED,  The  ELEMENT  IS  STILL 
INCOMPLETE,  INFORMATION  ABOUT  THE  ELEMENT  SHOULD 
BE  EMPLOYED  ONLY  AT  THE  USER’S  OWN  RISK,  *>, 

value*  complete 

(*  THE  ELEMENTIS  DESCRIPTION  SHOULD  BE  ASSUMED  TO 
BE  COMPLETE  And  WILL  PROBABLY  NOT  CHANGE,  *), 
VALUE!  CHANGEABLE 

(*  ALTHOUGH  ALL  RELATIONSHIPS#  ATTRIBUTES#  AND 

STRUCTURES  HAY  BE  DEFINED  FOR  ThE  ELEMENT,  SOME  OF 

them  will  probably  be  changed,  information  about 

THE  ELEMENT  IS  BElIEVED  TO  BE  CORRECT,  BIT  IT  IS 
SUBJECT  TO  CHANGE,  O, 
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ATTRIBUTE  I DESCRIPTION 
(*  TEXTUAL  DESCRIPTION,  *), 

applicable  element.typei 


value  I TEXT. 


alpha 

CATA 

CECISION 

entity.class 

ENTITY-TYPE 

EVENT 

FILE 

!NPuT_lNTERFACE 

pfssage 

origIn*t i ng— requirement 

OUTPUT-INTERFACE 

PERFOrhaNCE.REOUIPEmENT 

R-net 

SOURCE 

subnet 

subsystem 

lnstRuctured.reouirement 

VALIDaTI«N_PATH 

VALIDaTION_POINT 

VERSION, 


ATTRIBUTEI  ENTERED-BY, 

APPLICABLE  ELEMENT.TYPEI  alpha 

C ATA 

decision 

ENTITY-CLASS 

entity-type 

Event 

file 

INPUT_INTERFACE 

message 

CRIGInATING.REOUIREmENT 
OUTPl T-INTERFACE 
ferformance.reouirement 
F-NET 

Source 
SuBnE t 
Subsystem 

LNSTRuCTURED.REQUIREMENT 

valioation.path 

valiCation.point 

VERSION, 

value  I text 

(*  THE  IDENTITY  of  The  LAST  PERSON  Tp  ENTER 
INFORMATION  ABOUT  THE  ELEMENT,  *), 
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attp : bute  * gamma 


applicable 

VALUE  t TEXT 


(*  THIS  PROVIDES  The  PROCEDURAL  c 
INTERPRETED  By  pSl  PROCESSORS) 
MODELS.  IT  Is  PASSED  TO  THE  s 
AND,  SUBSEQUENTLY,  TO  THE  COMP 

element.typei  alpha, 

t 


ode  (which  IS  NOT 
FOP  ANALYTIC 

imulation  generator 
iler,  a). 


ATTRIBUTEl  INITIAL.VALUE 

(*  THE  INITIAL  VALUE  A DATA  ITEM  IS  REQUIREC  To 
HAVE  IN  THE”lMPLEMENTED  SOFTWARE.  THIS  VALUE 
WILL  BE  ASSUMED  By  THE  DATA  ITEM  WHEN  IT  COmES 
INTO  EXISTENCE  IN  A SIMULATION,  *), 
applicable  element.typei  CATA, 

VALUEi  named. 

VALUEl  numeric. 


ATTRIBUTEl  LOCALITY, 

applicable  element.type I DATA 

PILE. 


values  global 

(*  global  data  and  files  may  pe 
ASSOCIATED  with  EnTITY.TYPES  or 
ENTITY-CLASsES  or  may  BE  IN  THE 

global  data  base.  *), 

VALUEi  LOCAL 

(A  LOCAL  Data  and  FILES  are 

CREATED  and  INITIALIZED  FOR  EACH  ENABLEMENT 
OF  AN  R„NET,  A), 


ATTRIBUTEl  M AX IMUM.T IME , 


APPLICABLE  ELEMENT.TYPEi  VALIDaTION.PATH, 

VALUE:  NUMERIC 

(a  THE  maximum  TIME  THAT  CAN  BE  taken  TO  traverse  the 
VALIDATION  path,  a). 


ATTRIBUTEl  MAXIMUM.VALUE 

(a  THE  MAXIMUM_VALUE  APPLIES  TO  DATA  VALUES  ANp 
EMPLOYS  THE  LnitS  STATED  IN  THE  UMTS 
ATTRIBUTE,  a), 

applicable  element_typei  DATA, 

VALUEi  NUMERIC, 
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ATTRIBUTE!  MINIMUM-TIME 

(*  THE  MINIMUM  TIME  THAT  CAN  R£  TAKEN  T I?  TRAVERSE  THE 

validation  path,  *3. 

APPLICABLE  ELEMENT.TTPEl  V ALIDaTICN-PATH, 

VALUE | NUMERIC, 

ATTRIBUTE!  MINIMUM-VALUE 

(*  THE  MINIMUM_VALUE  APPLIES  TO  OATA  VALUES  AND 
EMPLOYS  THE  UNITS  IN  TH£  UNITS  ATTRIBUTE,  *), 

applicable  element.typei  CATA, 

VALUE!  NUMERIC, 

ATTRIBUTE!  PROBLEM 

C*  THE  PROBLEM  THAT  HAS  LED  TO  THE  NEED  FOR  A 
DECISION,  *), 

APPLICABLE  ELEMENT-TYPE  I DECISION, 

VALUE!  TEXT, 

ATTRIBUTE!  RANGE 

(*  THE  RANGE  OF  THE  DATA  IS  ENUMERATED  HERE, 

IT  IS  MEANINGFUL  ONLY  IF  ENUMERATION  IS  THE 
VALUE  OF  TYPE,  *3. 

APPLICABLE  ELEMENT-TYPE  I DATA, 

VALUE!  TEXT 

(*  THE  ALLOWED  VALUES  ARE  SEPARATED  BY  COMMAS,  *), 

ATTRIBUTE!  RESOLUTION 

(*  DESCRIBES  The  REQUIRED  maximum  value  of  THE  LEAST 
SIGNIFICANT  BIT  FOR  THE  DATA  IN  UMTS  DESCRIBED  In 
THE  UNITS  AtTRIRUTF,  *3, 

APPLICABLE  ELEMENT-TYPE!  CATA, 

VALUE!  NUMERIC, 

ATTRIBUTE!  TEST 

(*  PROCEDURAL  CODE  WhICH  DEFINES  THE  COMPUTATIONS 
NECESSARY  To  TEST  The  SATISFACTION  OF  A 
PERFORMANCE_REQuIREMENT  USING  OaTa  RECORDED  BY 
VALIDATION-POINTS,  *3, 

APPLICABLE  ELEMENT-TYPEl  PERFORMANCE-REQUIREMENT, 

VALUE!  TEXT, 


ATTRIBUTE!  TYPE 

(*  THE  TYPE  FOr  THE  D*TA  ITEMS  WHICH  ARE  REFERENCED 
ON  R-NETS  OR  ARE  USED  IN  BETA  Or  GAMMA 
SIMULATIONS,  *), 

APPLICABLE  ELEMENT-TYPE!  DATA, 
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R NET  START 


.IMAGE 


-INPUTJNTERFACE 

-VALIDATIONJOINT 

- ALPHA 

- ENTITY  SELECTION 
"AND" 


FOR  EACH 


SUBNET 


^HISTORY 

T)  READY 


-"CONSIDER  OR" 


.STATUS 


NOT  READY 


"OR"  REJOIN 


(X  >5.0) 


OTHERWISE 


(X  - 5.0) 


"AND"  REJOIN 

— "OR" 

T)Q— EVENT 

A— TERMINATE 


'OUTPUT  INTERFACE 


Figure  D- 1 Sample  R NET  Structure  In  Graphical  Form 


R_NET : SAMPLE. 

STRUCTURE: 

INPUTJNTERFACE  II 
VALIDATION_POINT  VI 
ALPHA  A 

SELECT  ENTITY_CLASS  IMAGE  SUCH  THAT  (Y  < Z) 
DO 

ALPHA  B 

FOR  EACH  FILE  HISTORY  RECORD 
DO  SUBNET  C END 
AND 

ALPHA  D 

CONSIDER  DATA  STATUS 
IF  (READY) 

ALPHA  E 
OR  (NOT_READY) 

ALPHA  F 
END 
END 

IF  (X  > 5.0) 


END. 


ALPHA  G 

VALIDATION_POINT  V2 
OUTPUTJNTERFACE  01 
OR  (X  = 5.0) 

DO 

ALPHA  H 

OUTPUTJNTERFACE  C2 
AND  ALPHA  J 
ALPHA  J 
TERMINATE 
OTHERWISE 
EVENT  Q 
TERMINATE 
END 


Figure  D-2  Equivalent  RSL  for  Sample  R_NET  Structure  (Figure  D-l ) 
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APPENDIX  E 
RSI  SUMMARY  BY 
ELEMENT-TYPE 


ElEHENT.TYPEl  alpha 
LEGAL  RELATIONSHIPS! 

CREATES! 

entitv.class 

DESTROYS! 

ENTITY..CLASS 

FORMS! 

MESSAGE 

IMPLEMENTS! 

VERSION 

INPUTS! 

DATA 

FILE 

OUTPUTS! 

DATA 

FILE 

SETS! 

ENTITY.TYPE 
DOCUMENTED  ("BY")! 

SOURCE 

EQUATED  ("TO")! 

SYNONYM 

TRACED  ("FROM")! 

DECISION 

ORIGINATING.REDUIREMENT 
LEGAL  ATTRIBUTES! 
ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

implement.approximately 

IMPLEMENT.PRECISELY 

BETA! 

TEXT 

COMPLETENESS! 

INCOMPLETE 

complete 

CHANGEABLE 

DESCRIPTION! 

TEXT 

entered.byi 

T”  X T 
GAMMA! 

TEXT 
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ELEHENT.TVPE  I DATA 

LEGAL  RELATIONSHIPS* 

DELAVSl 

EVENT 

implements* 

VERSION 

INCLUDES! 

DATA 

MAKES* 

MESSAGE 

ORDERS* 

FILE 

ASSOCIATED  ("WITH")* 
entitv.class 
entitt.ttpe 

CONTAINED  ("in")* 

file 

DOCUMENTED  ("BY")* 

SOURCE 

EQUATED  ("TO")* 

SYNONYM 

INCLUDED  ( " I N " ) | 

DATA 

INPUT  ("TO")* 

al^ha 

OUTPUT  ("FROM")| 

AL^HA 

RECORDEO  ( *B Y " ) » 

VALIDATION,. POINT 
TRACED  ( "FROM " ) | 

DECISION 

ORIGINATING.REQUIREMENT 


LEGAL  ATTRIBUTES* 
ARTIFICIALITY* 

ARTIFICIAL 

VALIDATION 

implement.approximately 

IMPLEMENT.PRECISELY 

COMPLETENESS* 

INCOMPLETE 

COMPLETE 

CHANGEABLE 

DESCRIPTION* 

TEXT 

ENTERED.8Y* 

TEXT 

INITIAL.VALUE* 

NAMED 
NUMERIC 
LOCAL  ITYI 

GLOBAL 

LOCAL 

MAX IHUM_VALUE I 
NUMERIC 

MINIMUM^ VALUE  1 
NUMERIC 
RANGF  * 

TEXT 

RESOLUTION* 

NUMERIC 

TYPE* 

real 

ENUMERATION 

BOOLEAN 

INTEGER 

UNITS* 

NAMED 

USE  | 

BETA 

BOTH 

Gamma 
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ELEMENT.TYPEI  decision 
LEGAL  RELATIONSHIPS! 

IMPLEMENTS! 

VERSION 

TRACES  ( "TO" ) | 

ALPHA 

DATA 

DECISION 

entity.cuss 

entity.type 

EVENT 

PILE 

InPuT.INTERFACE 

message 

OUTPUT. INTERFACE 

PERFORMANCE-REQUIREMENT 

R.NET 

SUBNET 

subsystem 

UNSTRUCTuRED.REQUIrFmenT 
VALIDATION.PATH 
VALIDATIO  N.P  0 I N T 
VERSION 

DOCUMENTED  <"BY">| 

SOURCE 

EQUATED  ( " TO  " ) I 

SYNONYM 

TRACED  ("FROM")) 

decision 

ORIGINATING. REQUIREMENT 
LEGAL  ATTRIBUTES! 

ALTERNATIVES! 

TEXT 

ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

I MPLEMEN  ^APPROXIMATELY 

implement.precisely 

CHOICE! 

TEXT 

COMPLETENESS! 

INCOMPLETE 

COMPLETE 

Changeable 

DESCRIPTION! 

TEXT 

ENTERED.BYl 

TEXT 

PROBLEM! 

TEXT 
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ELEMENT.TVPEI  ENTITY.CLASS 
LEGAL  RELATIONSHIPS! 
ASSOCIATES! 

DATA 

FILE 

IMPLEMENTS! 

VERSION 

CflMPOSEO  ("OF")! 

ENTITY.TYPE 
CREATED  ("BY")! 

ALPHA 

DESTROYED  ("BY")! 

ALPHA 

DOCUMENTED  ("BY»)| 

SOURCE 

EQUATED  ("TO")! 

SYNONYM 

TRACED  ("FROM")j 
OFCISION 

originating.requirement 
LEGAL  ATTRIBUTES! 
ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

IMPLEMENT.APPROXIMaTELY 

implement.precisely 

COMPLETENESS! 

INCOMPLETE 

complete 

Changeable 

DESCRIPTION! 

TEXT 

ENTERED.BYl 

TEXT 
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***  - 1. . 


ELEMENT.TYPEI  ENTITY.TVPE 
LEGAL  RELATIONSHIPS! 
ASSOCIATES! 

DATA 

FILE 

COMPOSES! 

entity.class 

IMPLEMENTS! 

VERSION 

DOCUMENTED  C"BY")| 

SOURCE 

EQUATED  ( " TO  * ) I 
SYNONYM 
SET  ("BY")| 

ALPHA 

TRACED  ("FROM")! 

DECISION 

originating.requirement 
LEGAL  ATTRIBUTES! 
ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

implement.approxihately 

implement.precisely 

COMPLETENESS! 

INCOMPLETE 

complete 

Changeable 

DESCRIPTION! 

TEXT 

enteped.byi 

TEXT 


ELEMENT«TYPE I EVENT 
LEGAL  RELATIONSHIPS! 

ENABLES! 

R_NET 

IMPLEMENTS! 

VERSION 

DELAYED  ( "BY  " ) 1 
DATA 

DOCUMENTED  C "B Y " ) | 

SOURCE 

EQUATED  ( " TO " ) • 

SYNONYM 

TRACED  ("FROM")  | 

DECISION 

ORIGINATING.REQUIREPENT 
LEGAL  ATTRIBUTES! 

ART IFICIALITVI 
ARTIFICIAL 
VALIDATION 

implement.,  approximately 
implement_precisely 

COMPLETENESS! 

INCOMPLETE 

COMPLETE 

CHANGEABLE 

DESCRIPTION! 

TEXT 

entered.byi 

TEXT 
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ElEHtNT«TYPFl  FILE 
LECAu  relationships! 

CONTAINS! 

DATA 

implements! 

VERSION 

HAKESI 

MESSAGE 

ASSOCIATED  « "WITH* 5 1 

entity.class 

entity.type 

DOCUMENTED  ( "BY " ) | 

SOURCE 

EQUATED  ("TO")  I 

SYNONYM 
INPUT  CT9")| 

al^ha 

OROEPED  ( "BY " ) | 

DATA 

OUTPUT  ("FROM"), 

alpha 

RECOROED  ( "B V " ) | 

VALIDATIO  N— P 0 1 N T 
TRACED  ("EROH")j 
DECISION 

ORIGINATI NG— REQU I RECENT 
LEGAL  ATTRIBUTES! 
ARTIFICIALITY! 

artificial 

VALIDATION 

I mplemen  ^approximately 
implement.precisely 

COMPLETENESS! 

INCOMPLETE 

complete 

CHANGEABLE 

DESCRIPTION! 

TEXT 

entered.byi 

TEXT 

LOCALITY! 

GLOBAL 

LOCAL 
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ELEMENT.TYPEI  INPUT_INTERMCE 
LEGAL  RELATIONSHIPS! 

CONNECTS  ( " T W * ) J 
SUBSYSTEM 
ENABLES! 

R„NET 

IMPLEMENTS! 

VERSION 

PASSES! 

MESSAGE 

DOCUMENTED  ("BY")! 

SOURCE 

EQUATED  ("TO")! 

SYNONYM 

TRACED  ( "FROM"  ) | 

DECISION 

originatinc.requirement 
LEGAL  ATTRIBUTES! 

ARTIP ICIALITY! 

artificial 

VALIDATION 

implemen  ^approximately 
IMPLEMENT.PRECISELY 
COMPLETENESS! 

INCOMPLETE 

complete 

Changeable 

DESCRIPTION! 

TEXT 

ENTERED.BYI 

TEXT 
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ELE^ENT«.TVPEI  message 
LEGAL  RELATIONSHIPS! 
IMPLEMENTS! 

VERSION 

DOCUMENTED  ("BY")! 

SOURCE 

EQUATED  ( " TO " ) I 
SYNONYM 

FORMED  ( "BY  " ) | 

ALPHA 

MADE  ("8Y")| 

DAT* 

FILE 

PASSED  ("THROUGH")! 
INPUT.INTERFACE 
OUTPUT.INTERFACE 
TRACED  ("FROM")| 

DECISION 

originating_requirement 

LEGAL  ATTRIBUTES! 
ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

implement.approximately 

IMPLEMENT.PRECISELY 

COMPLETENESS! 

Incomplete 

COMPLETE 

CHANGEABLE 

DESCRIPTION! 

TEXT 

ENTERED„BY! 

TEXT 
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ELEMENT.TYPE  I flRlGlNATlNG.RECUTRF.ME NT 
LEGAL  RELATIONSHIPS! 

IMPLEMENTS! 

VERSION 

INCORPORATES! 

ori&inating.requirement 

TRACES  CTO")! 

ALPHA 

DATA 

DECISION 

ENTITV.CLASS 

ENTITY.TYPE 

event 

FILE 

input.interface 

MESSAGE 

output.interface 

PERFORMANCE.REQUIREMENT 

R.NET 

SUBNET 

SUBSYSTEM 

UNSTRUCTURED.REQUIREMENT 

VALIDATION.PATH 

VALIDATIflN_PfllNT 

VERSION 

DOCUMENTED  ("BY")! 

SOURCE 

EQUATED  ("TOM! 

SYNONYM 

INCORPORATED  ("IN")! 

ORIGINATING.REQUIREMENT 
LEGAL  ATTRIBUTES! 

ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

IMPLEMENT. APPROXIMATELY 

implement.precisely 

COMPLETENESS! 

INCOMPLETE 

complete 

Changeable 

DESCRIPTION! 

TEXT 

ENTEPED.BYI 

TEXT 
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ELEMENT.TVPEI  dUTPUT.I^Tf RE ACE 
LEGAL  RELATIONSHIPS! 

CONNECTS  ( "TO"  ) t 
SUBSYSTEM 
IMPLEMENTS! 

VERSION 

PASSES! 

MESSAGE 

DOCUMENTED  C "BY" 3 I 
SOURCE 

EQUATED  ( " TO  " ) I 
SYNONYM 

TRACED  ("FROM")! 

DECISION 

OPIGINATING.REQUIREMENT 
LEGAL  ATTRIBUTES! 
ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

IMPLEMENT. APPROXIMATELY 
IMPLEMENT. PRECISELY 
COMPLETENESS! 

INCOMPLETE 

COMPLETE 

changeable 

DESCRIPTION! 

TEXT 

ENTERED.BYI 

TEXT 
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ELEMENT. TYPE  I PERFORMANCE.REGUIRFhENT 
LEGAL  RELATIONSHIPS! 

CONSTRAINS! 

validation_path 

IMPLEMENTS! 

VERSION 

DOCUMENTED  ("BY")! 

SOURCE 

EQUATED  ( " TO  " ) I 
SYNONYM 

TRACED  ("FR0M")| 

DECISION 

ORIGINATING.REQUIReMENT 
LEGAL  ATTRIBUTES! 

ARTIF ICIALITY  | 

ARTIFICIAL 

VALIDATION 

I mplemem  ^approximately 
IMPLEMENT.PRECISELY 
COMPLETENESS! 

INCOMPLETE 

COMPLETE 

Changeable 

DESCRIPTION! 

TEXT 

ENTERED.BYI 

TEXT 

TEST! 

TEXT 
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ELEMENT-TYPE!  R.NET 
LEGAL  RELATIONSHIPS! 
IMPLEMENTS! 

VERSION 

DOCUMENTED  ( "BY") I 
SOURCE 

ENABLED  ( "BY " ) I 
EVENT 

input-interface 

EQUATED  ( "TO " ) I 
SYNONYM 

TRACED  C"FROM")| 

DECISION 

originating.requirement 

LEGAL  ATTRIBUTES! 
ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

I MPLEMEN  ^APPROXIMATELY 

implement.precisely 

COMPLETENESS! 

INCOMPLETE 

complete 

Changeable 

DESCRIPTION! 

TEXT 

ENTERED_BYI 

TEXT 

LEGAL  STRUCTURE  ELEMENT..T  yPES  l 
ALPHA 
EVENT 

input-interface 

output.interface 

subnet 

validation-point 


ELEMENT-TYPE!  SOURCE 
LEGAL  RELATIONSHIPS! 

DOCUMENTS! 

ALPHA 

DATA 

DECISION 

entity.class 

ENTITY-TYPE 

event 

file 

INPUT.INTERFACE 

MESSAGE 

OPIGINATING..REQUIREMENT 

output-interface 

PERFORMANCE-REQUIREMENT 

R-NET 

SUBNET 

SUBSYSTEM 

UNSTRUCTURED-REQJIrEmemT 

VALIDATION.PATH 

validation.point 

VERSION 

EQUATED  ( " TO " ) I 
SYNONYM 

LEGAL  ATTRIBUTES! 

ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

implement-approximately 

IMPLEMENT-PRECISELY 

COMPLETENESS! 

INCOMPLETE 

complete 

Changeable 

DESCRIPTION! 

TEXT 

ENTEPED.BYI 

TEXT 
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ELEMENT„TYPEl  subnet 
LEGAL  RELATIONSHIPS! 
IMPLEMENTS! 

VERSION 

DOCUMENTED  ("BY")! 

SOURCE 

EQUATED  ("TO")! 

SYNONYM 

TRACED  ("FROM")! 

DECISION 

originating„requjrement 
LEGAL  ATTRIBUTES! 
ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

IMPLEMENT. APPROXIMATELY 

implement.precisely 

COMPLETENESS! 

INCOMPLETE 

complete 

changeable 

DESCRIPTION! 

TEXT 

ENTERED.BYI 

TEXT 

LEGAL  STRUCTURE  ELEMENT.TyPES  | 
ALPHA 
EVENT 

output.interface 

subnet 

VALID AT ION.POINT 


ELEMENT..TYPEI  SUBSYSTEM 
LEGAL  RELATIONSHIPS! 
IMPLEMENTS! 

VERSION 

CONNECTED  ("TO")l 

InPut.interface 
output.interface 
DOCUMENTED  ("BY" ) I 
SOURCE 

EQUATED  ("TO")! 

SYNONYM 

TRACED  ("FROM")! 

DECISION 

ORIGINATING-REQUIREMENT 
LEGAL  ATTRIBUTES! 

ARTIF ICIALITYI 
ARTIFICIAL 
VALIDATION 

implement.apppoximately 

implement.precisely 

COMPLETENESS! 

INCOMPLETE 

COMPLETE 

CHANGEABLE 

DESCRIPTION! 

TEXT 

entered„byi 

TEXT 
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EU£MENT«TYPEI  SYNONYM 
LEGAL  RELATIONSHIPS! 

EQUATES  ( "TO" ) I 
Alpha 

OATA 

DECISION 

ENTITY.ClASS 

ENTITY..TYPE 

EvEnt 

FILE 

INPUT.INTERFACE 

MESSAGE 

ORIGINATING«REQUIReMEnt 

output^interface 

PERFORMANCE.REQUIREMENT 

R.NET 

SOURCE 

subnet 

SUBSYSTEM 

UNSTRUCTURED.REQUIrEmenT 

VALIDATION.PATH 

VALIDATION.POINT 

VERSION 

NO  LEGAL  ATTRIBUTES 
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ELEMENT. TYPE  I UNSTRUCTURED_RtQUlREMENT 
LEGAL  RELATIONSHIPS! 

implements! 

VERSION 

DOCUMENTED  ( "BY" ) I 
SOURCE 

EQUATED  ( " TO " ) I 
SYNONYM 

TRACEO  ( "FROM" ) | 

DECISION 

originating.require^ent 

LEGAL  ATTRIBUTES! 

ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

implement-approximately 

IMPLEMENT-PRECISELY 

completeness  I 

INCOMPLETE 

COMPLETE 

Changeable 

DESCRIPTION! 

TEXT 

enteped.byi 

TEXT 
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L 


ELEMENT_TYPEI  V Al ID A T I ON_P A Tp 
LEGAL  RELATIONSHIPS! 
IMPLEMENTS! 

VERSION 

CONSTRAINED  ( "B Y " ) * 

perf  ormance.requ i recent 

DOCUMENTED  ("BY")| 

SOURCE 

EQUATED  ( "TO " ) l 
SYNONYM 

TRACED  ( "FROM" ) j 
DECISION 

originating.requirement 
LEGAL  ATTRIBUTES! 
ARTIFICIALITY! 

APTIFICIAL 

VALIDATION 

implement.approvimately 

ImPlEMEnT.PRECISELy 

COMPLETENESS! 

INCOMPLETE 

complete 

changeable 

DESCRIPTION! 

TEXT 

ENTEPED.BYI 

TEXT 


MAX 

JM 

UM_TIME  l 

NUMERIC 

MIN 

IMUM„TIME| 

NUMERIC 

UNI 

TS 

1 

NAMED 

LEGAL 

P 

ATH  ELEMENT, 

EVE 

NT 

VAL 

ID 

ATION.POINT 
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ELEMENT^  T YPF I VALIDATION..  POINT 
LEGAL  RELATIONSHIPS! 
IMPLEMENTS! 

VERSION 

RECORDS! 

DATA 

PILE 

DOCUMENTED  ("BY")! 

SOURCE 

EQUATED  ("TO")! 

SYNONYM 

TRACED  ("FROM")! 

DECISION 

originating.requirement 

LEGAL  ATTRIBUTES! 
ARTIFICIALITY! 

ARTIFICIAL 

VALIDATION 

ImPlEMENT.aPPROMMaTELY 

implement.precisely 

COMPLETENESS! 

INCOMPLETE 

complete 

Changeable 

DESCRIPTION! 

TEXT 

ENTERED^BYl 

TEXT 
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1 


EL£MENT,TVPE » VERSION 
LEGAL  RELATIONSHIPS: 

DOCUMENTED  ( "BY" ) | 

SOURCE 

EQUATED  ("TO")  | 

Synonym 

implemented  ("ry")» 
alpha 
data 

DECISION 

£ntity_class 

ENTITY_TvPE 

EvEnT 

FILE 

I NPUT_I N TERF  ACE 
MESSAGE 

ORIGINATING..  REQUIREMENT 
output„interface 

PE  RFORMANCE«REQUIREMENT 

R„NET 

SUBNET 

Subsystem 

UNSTRUCTURED.REOUIrEmenT 
VALIDATION_PATm 
VALIDATION.POINT 
TRACED  ("FROM"  ) j 
DECISION 

Originating.,  requirement 
LEGAL  ATTRIBUTES* 
artif iciality: 

ARTIFICIAL 

VALIDATION 

implement^ approximately 
ImPleme;nt_pRECISELy 
COMPLETENESS: 

Incomplete 

complete 

Changeable 

DESCRIPTIONj 

TEXT 

ENTEPED.By J 
TF  XT 


' 
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APPENDIX  F 


TRACK  LOOP  SYSTEM 
RSL  REQUIREMENTS 
KERNEL 


F-l 


R.NtT:  CC_PESF*r  SE . 

REFERS  T«s 

AL^ha:  AC*  . 3*  lEDoE. 

aI°wa:  CC_E  ^R"iR_RrI"CF  RS  I n-G 

A l Rha  I e.  k-7i  A GE  If-  NT_Ikit  1 at  I o.w 
ALPHAS  STARTER 
A I 0 H A J TF  K ‘'_F  M & AGE  H f K T 

ALPHAS  TEH  '_TpAC* 

ALPHAS  TR  ACK_IN.IT  I ATE 
A I P H a s V A L Tf'ATL«.wF.  Ar>f(j 

Data:  rr^M  "A'lii^iu 

DATA;  F3l.if,0 
DATA; 

DATA:  TMAGE^Io 

E Kl  T I T Y_C L*s rT  IhaqE 
EVENTS  a L L r'  C A T F 

EVEMTs  SCHEDULE 
EVENTS  sun h AR  I 2t. 

I H P " T _ I n T c R F A C E 5 Ct_TM 
0 1 1 T P U T_ I f-i T c. '< F A c F ; (.r_MT 
OLTP  u T _ I *J  T F R F ACE  S C A T A_  R c C 0 P 0 

S ' ’ '3 N E T T R[;CnfiO.OBoF 

V ALIOAT  T 0'-l_F  3 I T J ( ?_  T h a G H A U 0 T*  V L R 
VAL  I DAT  lr>'v“t'3l  ; T j START  I N{i~P  * I N T , 

ENABI  Er  Rv  5 

Ivput_I*.tfrf  ace  : cc_ih, 

TRACED  F R o M : 

0 R I r,  j m a t i m r,_  R E ‘J  U I R e h F k T s 

Tl  S_f3PSPR_P ™RA(;RaPm_3_?_  j_A_FiWr  T I o\  AL_ Rf  QlIREHEUTs 
ORIGIN  AT  i”g_RF.3UIBeFF.KT*8 

T L S_DPSPR^P  AR  AGR  ApH„^_?_2_F„FU  ir  T T ‘,''AL_RtGUTH'E  ME  NTs 

0RIGIUATi”g.RE'3UI»e”f>t7 

Tl  S-DPSPr.<.PARAGPAPH_3_?_5_A<_FU^C  Tlf'vAL_REtJOIRE^EMTs 
OR  IG  I N A T J ”g— WF.Ol1 1 Be”f~  tT 

Tl  S_DPSpr_PARAgRAPh_3_?_S-h_f  iinc  TT  n „aI  _REGu I REMF  n»T$ 
OR IGIMAT i”g_RF JUIPe”e”t7 

Tl  S_()PSPR_SUHSECT  ION_3_?_t_fUNCT  I Of.AL.RtQUIRfc  MEATS 
OR IGINAT ING.wE JUIREFeaTs" 

Tl  S^pPSPR.S'iHSEC  T I nK_3  l S_F  U^C  T I "'v  Al.RF G.U I REMt  N T S , 
STRUCTURE; 

IAPI'T_INTFRFACE l CC_IN 

ALPHAS  V AL  1 1>  A TE_h£  A Gt  R 

Df 

ALPHAS  ACKUO  JL  EF>gE 


BEST  AVAILABLE  COPY 
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^JTPUT^riT'Wf'ACfc  ! CC_"iiT 

) 

CflNSTFFR  riAT4:  c',*f^AN0„I^ 

IF  (HANDPvE  R—  T M aG£  ) 

ALPHA:  t”aCK_ [E  I T I A T F 

VALID*  n.^^PflTNT  • C?-r‘AGE_M<'f  Hf-tvfO 

rVENT:  Ai.  l^C  A Tt 

01 H P U T_  I ' T f R E a q t : C A T A_c  r c P R P 
OP  (IE  TT  I ATE^Ff-.GAGEMF‘'!T_-in”t  1 
a L f n a : 5 t a p i t r 

V 4L  T;'A  l I ImT  j 5 T APT  I ng_p o I ' T 

A I.  p m A } E >'GA  GE  '»E  NT_  T N I IIATJAM 
r.vf'Tj  schfo"lE 
FVT-.T!  SUMMARIZE 
T F » M I ' A T F 

op  ( T E p;i  T I A TE^FNGaGE  N<FK  T.'-f'DE  ) 

A L F H A : T E P E N G A G F M E T 

T E R M I M A T E 

CP  ( or np_ track) 

SELECT  E JT  I T Y_cL  ass : I "AGE  S « • C M That  l,  I At.E _I  D = hO_  I D i 
I F FF^u^n) 

SiiHMFTS  RF^PPp  P(.’^P 

ALF'^Aj  TFRm.TraCi- 
■iiiTpur^rNiEpF  acf  r oat a_pef :'‘-ri 

fiTHcprt  [SE 

alPm a : cc—t  Fpf'p^pp^ct  sstmg 

TE.jp  > ’ T j A T F 

F NO 

OP  (CC_mESSAGE_F.RrOR) 

ALPHAS  CC„F  RRoR^pp'icF  SSI  MG 
T E F ! 1 1 '<  A T E 

F NP 


Ef  0 
EMC. 


R-NETs  c ^ m T ^ ^ I f f S T'jPCt.  3 , 

deSef  if  r r «m  : 

"The  i L S_OpS  s <- a l 1 


:E  vjlFF*  F'-Tis  SPFCIF  IFo 


I U The.  p f S f 
AMD  C11  •'  I F <L 


- HEFEPJf-r.F  ?,?,  ASS^rtfiTFO  MTh  MANAGEMENT 
*F  Tl  S PFS^URCfS  A f n S'-'Al.l  F'  E •<  r C fp  M T^E 


f u m c r i 
R_f  L T . 


/S  HEREIN  PFFT^EP  AMP  nT  AGRAHt'l  o 


t hr  ops  shall  assign  track  rates  fi'n.  energy  allo*ancfs 

TO  F.ACm  I^AGF  HANpfn  OVER  FR  Ol*  C ^ M A N U AND  cflNTR*L 
AMO  Shall  OE  T F Rh  T MF  FMFRGV  H^LIN'OS  At.o  T h A c K RaTe 
F'TVt  I T'^ES  Fi^R  EACH  H A 14  0 ? V E R IkfAC,E  *HlCH  REGAINS  In 
T w a C k STATUS,  The:  F.nFRGY  pOl.'MoS  AND  TRACK  &atE 
EnveL^PFS  ShALI  pF  mainTainE1  *IThIm  am  ACCURACY 
a I'd)  R£  S 'L  UT  I pm  TOLERANCE  SUEFICIFET  TO  m£  L 1 The 
SPEClFlEC  R E G l 1 1 R E m E mTs  riap  Of  TE  rm  I M a T I ft;  SF  TaRGFT 
InURCCPT  CO'  PI  T rp'-s, 

THF  OPS  Shall  ASSESS  status  of  THf.  TLS  RESOURCES  AN'C 
shall  allocate  tls  resources  to  face  hanccveR  image 

haSEO  *N  radar  smSYSTfM  PC  RE  OR  mae  CE  CAPABILITIES 
A 1 2 0 S h ' L I 0 A 1 NT  A U.  A GRArE.FUL  OeGFACATION  PASTURE 
a h i l F "mOER  Overload  conditions, 
the  ops  Shali  generate  tls  RESOURCE  UTILIZATION 


* I 


r 


mmmmusm 


p R * F I L E S ANp  SmaLl  CftK,MIT  TUPS'-  Pata  T *“  PE  R k A N £ n T 
PILL  THj(»ur,H  T RE  0 A T A RECORD  Cl  I * T P’  U T INTERFACE,", 

refers  r*; 

AIPha:  A S3 1 GM_ R A Tfc 

AL  RH  A J C'TE  A TE^S  r AtP_F  H E 

AIPha:  f.Rf)P_L^S  T 

alpha:  m A(\p— all OC a t I 

El  TIT  Y^TyP'E:""  I M A Gl_  I N_T  ti  A L k 

ENriTY_TYDt:  Lf’ST_P(l|  SE 

ET  TI  TY_TY^e  - HE  Tl)RPFr_P|,l  sr 

subnet;  t ally^petuR'isT 

EMAblEO  by: 

Event:  allocate, 

TRACFO  F H n *1 : 

APIRlMATINf.^REQUIHE*-  ENT  ! 

TL  S_pPSPR_HARAGP  APH<.3_?_>3_D_F||NICT  I rTf"AL_kE  QLIREmENTs 

•ip  in  I ‘l  AT  i"g.PE  Ql'I^VF  KtT 

T ( 3_r>PSPP_PARAnRAPH_}_?_a_A_FH  JC  T I 0 s a I _R£  <3u  I k Er*E.  N T s 
pp  in  is  at  i”g-re:ti|ipe”ent7 

Tl  S_BPSPH_PAPAc;P  AF*h_3_2_'J_fj_F  tl-JCT  lr’'  AL_f't  •»  L I R E ’ 1 E N T S 
0R  inis  AT  I ‘.f,_H)P  u’M  I K p f F “t  ! 

Tl  S.IlPSPr.S'  '-»SEC  T I 0P_T_?_')_tF'LJ-JC  T rT"A|  r.U  1 Pt~lt  T T s . 
STRUfH'PF; 

Df 

F IP  [trfl  F : T I I Y_j  Y PF  . Rf  TURNF  n^H'LSf 
p * S i.!  H k K T I T 4 L L Y_  P F T ' 1 R N S E A.  r> 

AND 

F’F  FAT.)  L l T I T Y_t  VPF  • L n S T_PI  'L  SB 
p*  ALc’HA:  PPPp^L^ST  ENC 

A A D 

F ip  EACH  E |TIIY_TVPF:  I h a g E _ T n_  T p A C K 

[>ft  ALPHA;  r.»~A  TP  sTaIE.PILF  7 /' 

EE  0 

ALPHA;  wAKt.—  all  YC  a T I f\ 

Ff»  EACH  t ' ~T  T Y^T  YPf  : TNAnF.r-^TPACf 

P'l  ALPHA!  A $ 3 T G ‘ __  H A T F L'-D 
TERMINATE 
ENC, 


R_NEf:  RADAR_Sl.iMPAPY , 

REEEpS  T«: 

alpha;  c-’-'PlE  te^Sijm.  Apy 
DATA;  ‘iM>t 

EEiTT  T Y_T  YPF  : PE  T i irK  f i;_p  Lll  S'" 

EVENT:  SUF-"ACI?E 

OUTDiiT_.tr.  tl  peace  : r at  A_KEC,,Pr> 

S"t*NfcT:  E Tl.'R-jS  . 

ENABI EP  h y : 

EVENT:  s i.i  i ■ a R i 7 fc  , 

Tk ale  D Eppw: 

PE  mis  A T I Ni;_RL  JII  IPle  E n T : 

Tl  3_pP3PK'_F  A P A n P APm_  3_  ?_  '<_A_F  i)  Jf  1 T 0"  AI._K{  r-’U  I E<  E KE  NTs 
0PIGINAT  INr.i_PE'T"IPtE  E~  t” 

Tl  S_PPSPH_E  WAr,R »i’H.  3_?_S_l)_FUNr  T I iV . A l _k f Gl  IRENE  M S 
9P I GIN A T 1 NG_RE  TL I »£  E E ” tT 

Tl  S_DPSPR»S"nSEC  T I fiE_3_2_y_FuNCT  I I*iE  Al_RE  (JJIRLmEN  T S 
OP  IGJNAT  ING^RF.GI'IRf^FnT  :” 
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Tl  S— DPSP^!_ S'JHSt C T I p»K—3  ? S.FunC T 1 On  AL.REu'.1  I RF  MEN  T S , 
S T»UC  Ti ic?e  S 

consider  data;  mode 

IF  (ENGAGED) 

FOR  F 4 C H F M T I T V^. T V P E j RET  IjRNf  D—P UL  St 
O'*  SUBNET  1 SUm_.RETI.rns  END 
ALPHA ; CouPLETE.SLmmaKy 
FVEkjT;  SU'1-*  ARIZE 
0 U T P U T _ J ‘ ■ T F R F ace:  n A T A_Pf  c pro 
PR  (STANPRY) 

TERMINATE 

EM) 

END. 


R.NETj  RAOAR.TIF'JMG, 

DESCRIPTION; 

"RADA  R_T  1 V I \ Q MAIFTATNS  a F?  F C f*  R P OF  THF 

RAOA(7”CLf,CK_TI'yE . " , 
refers  tpj 

alpha:  u p d a t e _r  a d a r _c  l * c * 

I ^ U T_  I N T F rF  a C e:  : R A D A R_  c L PC  K_  I K , 

ENABLEn  PyT 

in  PI  IT.  I N Tc  h’F  ace  S rap  AR_.CLOCK._Iki  , 
STRUCTURE:" 

ik  ph r_ interface:  r ad  a r__cl  oC  k_ i n 

A l P H A J tJPUATK -RAt)AR_CLPCK 

TERMINATE 

END, 


R_NET|  RF  SP^NSF.  _T  fi.RApAR, 

DESCRIPTION: 

"The  TLs_nps  Shall  implement  ThF  RE'JUIREK  ENTS  SPECIFIED 
IN  THE  TlS_WADA9_nps_riTFRFACE_5f'tClFlCATIPN  ASSOCIATED 
* I T h PROCESSING  M Pa"  SUf-SYSTEH  RESPONSES  To  COMMANDS, 
and  Shall  PEPFPpN  THE  FUNCTIONS  ^ 1 1 T-  l.FF'I-FD  A NO 

DIAGRAMMED  pi  ThF  R f S P R A 0 R_k.£T, 

THF  OPS  Shall  RECEIVE  AND  PRf'CESS  K A 0 A R M t SSAgES 
transmitted  R Y IHt  TLS  RADAR  SUBSYSTEM  aK  D Sm 4 LL 

interrogate  each  message  for  errors  and  shall 
PROCESS  all  t F T F C T F D message  FRrMS, 

THF  tps  SHALL,  UPON  RECEIPT  of  EyPOR— F Rt  E RAOaR 
MESSAGES*  PeTFCT  and  PROCESS  RF pUK D AN T_1 K AGE S * 

G H o s T _ I m a G E s * AND  LPW^ELFVAT  T0N_H  AGES,  AND  ShALL 
update  STAt^parapF tfrs  for  Each  image. ik. Track t 
THF.  r'PS  shall  terminate  track  on  each  ImaGF  khICH  Is 
PETEtt  -'INIF.D  TC  PF  El™ER  A PfOUNDAK  T OR  GPOST  I^aGE 
or  which  IS  Found  TO  EXCEED  The  L 0 R.F LE v A T I ON 
CONSTRAINTS  and  Shall  MAINTAIN  track  on  each  image 
DETERMINED  to  p F real, 

ThF  OPS  Shall  construct  AND  maTnTaIN  DESCRIPTIVE  DATA 
FILES  for  Each  image  which  is  FITnER  maintained  in 
TRACK  09  DPoFPFD  from  track  AND  SHALL  PfcRIOpICALL  Y 
COMMIT  THESE  DATA  TO  PERMANENT  RECORDS  1 RROyGH  T WE 

DATA  records  interface.", 

IMPLEMENTS: 

VERSION:  p )L?_COuPlLEP_LlMI T ATTon^compEnSaTION, 

BS1  AVAILABLE  COPY  j 


REFERS  T"; 

AIPhai  fUrh^UPDaTe 
AlPHAt  GHpST.orTERFlKATjPN 
ALPhaj  GwOST-.TERHjAATjf)^ 

alpha:  l^w_eLE  va  t jf  m_hE  tERmInati 
alpha:  li^-^RmP'at 

ALPHA:  WEI  UN_OF  TF-Rf  i k a t i nn 

al°ha:  RED'Jf|_TERHlF>  AT  ] Pfj 
alpha:  rfmE  ^ER^StOR 
aiPhaj  RR_f  wRffp.PpC’CF.  SS  I NG 
alpha:  iJPL  4 TE_S  T a yf 

DATA:  FI UNO 

DATA:  G H f ■ 5 T — I < AGE 
DATA:  ,T;M,\r,r_lO 
DATA;  L^.ELf  Y A T T 1 N 
DATA;  PiJL  SE_I  D 
DATA;  fiJLSE_rYP£ 

DATA:  RADAR"  TYPE- 

DATA:  P t l1i)N-i)  A N T_  I m A GF 

DATA:  r J^flOnC.^To 

data : targe t_i” 

data*  valiO_RetijRm 

tf1  n TV_CI  AS"  : I M a g f 

Ft,  r I T Y_CL  ASS  : PUI.SE 

fctv  TITY^TYPt  : IHAGt-TN_ERACK 

I m d u t—  i m t e t«  r ac  t : p ada”_  i n 

3llfPUT_TF'Tt  PEACE  : P A T A_RE C "RO 
SI'-YMt  T : rx  TRAC  T_“fc  ASLip"  f-E  NT 
Sl'HHfTj  h j S 3 I ’ I Ci”  R £ T IJ  R k S 

SIDNEY;  R £ C ■* R 0_  U c ft f : , 

ENABLE"  R Y : 

I h P i I T _ I N T L E AC  E : R A n A C_  I f . 

TRACFl)  Fcp”. 

HR  IGINAT  I1  i.,.Pf.Ot)lR[  f'F  KT  ! 

TL  S_DPSHR_F  A R 4 G R A P h—  3 A_FHNr  T I r»f 1 a l _Rt  QU I REf  t NT  s 

flp  IGINAT  JOG^Rp  T.iIWe."f  nt7 

T ( S^DPSPR^PAPAr.R  aPh_  3 p-^-rt_F'J,JC  TIPNAl_REOL'If<Ei*FN'Ts 
f1PlGINATl'-G«.REDi.iIRL~FKT7 

T L S_DE SPR_f’ A a c,R  A Ph_  3 ?-?_C_FUMC  T I ft"  aL_R|  GUI RE^ENTs 
0PIGINATi"c..REDOIReHf“t” 

T | 3_f)P  SPR_('  A ^agraph_3  2-2_0<ipFilNCTIflt.AL_RE  UL  I REf:E  F:  T s 
f1»  IGIt'AT  l”G.PE')OI»t”FlT7 

TL  S_DPSPK_PAR  AGR  APH_  3 2_3.a_F  IJMC  T I ft ' : AL_Pp.  Gb  I RE'-'F  NTs 
(1  PIG  I NAT  i”g„wf  GUIRe^'tT 

TL  S.OPSRw.RARAgRAPh. 3_ 2_ 3_H_F iJNf  T I «'■  AL_RF  QL  I RE1'  F NT s 
ORIGIN  AT]  '«i.,_RF  )UI  RE  REK  T : 

T I S— PP SR h_P  A W A QP  A R h—  3_  3— C„F  1 1 'JC  T I f A L _R t GblREf'E  F T s 

(1R  l"l  fA  TING^RE'JOIPeREat” 

TL  S— Op  S E R— R A I?  A 0 P A P 3_  2_  3_F  _ F U Nf  T T Pi  AL_P|  GIjIREHF  NTs 
OP  I G I n A t T n G. RE  >JI.|  I Rp  f F N t7 

T I 3_PP5PKj-RARAr,RAPH_3_2_,3_P„E  H'JCT  IN1  aL_RF  QblR'FT  ENTs 

itr  iginatigi^rf:  ,hhre"e“t7 

Tl  S-iDPSPR_RARAGRARh,3_?_5-C-F'UNC  TI'!'  Al_Rf  UblRE'-  f NTs 
ORIGINAT  i"g«.RE'J1'1wE*ENt7 

TL  S_ P ° 3 P R_ S 1 1 h $ E C.  T I 3 F ^ "3  2 2_FUNCT  I *"■ A L_«E MJ I RE MLN T S 

origin  at  i”g^rEiju  i Recent 

TLS.DPSPR’.Sltr’SEC  TTpT  mi  2 3_F  UNC  T I ON  al_REgUI  PEMtF  TS 
origin  A Ti’g«.RE'J'JIRe^FnT: 
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TLS_DPSRR.S'mSEC  T I QN.3_2_5.F  UNCTION  al. REQUIRE  HEMS, 
STRUCTURE: 

IKPlir^lNTEHFACt : RA[)AB_TN 

SELECT  EMIT  y.C L A S S : P~lSE  SUCH  That  (PULSE.IOshF.OrDER.ID) 

IF  (FOUND) 

IF  (WADAB.TyPEsPl'LSE.TVpF  ) 

on 

ALPHA*  FEHfcNfiEF^STnP 

FOR  EACH  EnTITV^CIASS:  PULSE 

on  SuPnEt:  m I SS I F'G_Rf  T < ’ R f ■ S EM 
StLECT  EM T TT_CL ASS:  PULSE  SUCH  THAT 
fPULSE-lCsPR.PPOEP.If' ) 

terminate 

AND 

subnet:  e*tl  act.me  asurehem 

IF  (VALIC.RETURM 

alpha:  IjFntTf  STATE 

on 

AlFH  A : L^^^ELE  V A T I nK._r>t  TEKM  I a T I fJA 
IF  (LOR.FLEVATION) 

S'lREETj  PfcCBRO.DPPP 
ALPHA*  L ”w-TE'rt”l  * A T I UN 
!'1MtFI)T_I*jTl"f  ACF  : UAT  A_f-  ECPFf 
fTHEPwISE- 
TF  RF  I F A T E 

e sir 

A ' NS 

ALPHA}  F ORM.lJPD  A T E 

HJTPUT- INTERFACE:  hat  A^PECfRl 

and 

for  faCh  Entity. type:  tmage.tn.i pack 
such  that  ( ivAC,E.if 01  awdf r_ii  ) 

on  ALPHA.  Ffc.DUN.0l  Tew'h  iTa  1 I ON  END 
SELECT  F NT T T y_CLASsT  IhAgE  SUCH  THAT 
f I^aDe. Tf=T aRGFT_I0) 

IF  ( » e. ( UNpAnT^im AGE  ) 

SUnf.FTr  RECORO^drop 
ALPHA  j PE  OUN.TE  Rv  I k-  A T I n a 

nuTF  ut_i  ntepe  ace  : <»« T a.i  e c oro 

n THf  R*  I SE~ 

TErf  INATE 

E NIP 


END 

otherwise 

AL  PH  A : GP(,ST.DFTERmI  NATION 
IF  (GHOST.  I * AGE  ) 

Subnet:  pE C rtRP_Cwnp 

ALPHA.  G M n S T. T E P 1 1 N A T I p N 

njTP u t. interface : pata^recorc 

.sTmF  pi*  i Sf 

Tf  R MnATf 

END 

END 


END 

OTHER  Hi  TSE 

alpha:  rr.errcR 

TERmINaTE 

END 


PP*CE  SSING 


r 


OTHFSwJSf 

ALPHAS  RR.ERROR.pRflCF SslNG 
TERMINATE 

Ef  D 
END, 


R„NETs  S*ED.R, 

DESCRIPTION; 

"SKFD.R  cf’  NSTRUCTS  The  ORDERED  file  OF  Data  FPL 

A FRAME, ", 

REFERS  Tps 

alphas  INIT  I Ai_  I ^E_SKfn_R 
alphas  PIC*_CANCId4TcS 
DATA}  LAS  IMPULSE 
DATA}  Mfir>£ 

DATAs  te^f 
datas  trac karate 
EMTITY.TYPES  :MAGE»IN_TRACK 

events  XRH 
F ILF  s CANDIDATE 
Subnet:  fcrm.fram^, 

ENABLED  by  S 

event:  SCHEDULE, 

TRACED  FRfiMj 

DECISIONS  RADAR_ScFECULEw.pRI,,,RlTl7ATieN 

0 R I G I N A T I N G_ R E !5U  I R E F“ E N T S 

ILS_OPSPR_P  AR  AGR  APh.3_?_2.A.FUNC T I ON  AL.RF.GU  I REF  t NT$ 

opiginati"g.rEijuire”ent” 

TL  S_DPSPR_r ARAGRAPh. 3_?_P_B_FUnc  T I 0N At_R! Qu I REDE  NTs 
OR IGINA T ING_REQUIReN£~t7 

Tt  S_DPS'3R_PARAG»APh_3_?_2_C_FUNCT  T O'- AL.RF  UU  I REF'F  N T S 
OP IGINA  T i”g.RERUI«e”e~t7 

T L 5_DRSPR_PAR4GRAPh_  3_?.2.D_FUNc  T I ON AL.RF  OU  IRENE  NTs 
ORIGIN  AT  ING_REQUIREnEM  S 

TL  S_DPSPR_F ARAGRAPH_  3_?_P_E_FHNr T I PF  AL_RFQUIRFF  E NTs 
OP  I GIN AT ING.REDNIPtFEN t“ 

T l S.DPSPR.R  AR  A GRAPH.  3_  ?. 3.D.FUNCT  10  NAL.Rl.  QUIRE  FENTs 
a R I G I N A T I N G„  R E Q U I R E D F N t7 

Tl  S.DP  SPR.P  AR  ' Gw  AP  h.  3 p_3.E_F"NCT  I 0 kl  AL.RF  QU I RENE  N T5 

origin  at  i”(,_rf;qui«edent7 

TL  S.nPSPR.S'lHSEC  T I oF.3_P_?_FUNCT  I on  al. REQUIREMENTS 
OPIGINAT I NG.RE QUIRE RENT 

Tl  S.DPSPH.SIHSEC  T Iijl  .3_2_3.F  UNC  T I ON  AL.RF  QU I RE  Mfc  NTS, 
STRUCTURE: 

CONSIDER  DATA:  MODE 
IF  (ENGAGED) 

ALPHA:  rNl Tl ALIZE.SKFD.R 

FOB  EACH  F J T I T Y.T  v PF  s “ l M A GE_ T N. I P A C K SUCH  THAT 
( L a s T.PiJLSE  + ( l ,0/tRACk.RATF  )<TF  of) 
no  alphas  PIC*. candidates  end 
for  EACH  FILES  C A N D I C A T t RECORD 
po  SUPfJETS  F OrR.FrAmF  F mq 
F VENT  S XRH 
T E R M T N A T E 
OP  (STANDBY) 

TERMINATE 

END 
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A 


ENC. 


R.NETj  xMl.f, 

D 1 5 C F IPTl  «*j; 

"xm!T_p  h'irLDS  K\ f f^p-ards  r r the.  ^ y t r t • r_  I \1  FRF  aCE 
padap_out  the  commands  the 
REFERS  T 9 ; 

A l P*A  S Ff*Pl‘,_T  t_T«? 

Al  Pma  j F TP  4_T 3 
Al  PHi;  PIC'.CfjMA’A^r 
MPha;  SE LEC T_C0MMANr 
DATA;  RAOAP^TyPE 
DATA;  RECORU^F  HJNf) 

E V E ^ T t SChEO'jlF 
E V E NT  j *«P 

? 1 1 T P U T _ | 4 T E P F A C E S P A[>  aR_OI.IT 

VALIDATE  \_p  o I n t • p apa  e“cflNMANp_fmTpiiT-po  ] mt  , 

ENABLED  KYJ 

EVENTS  X«H. 

TRACED  FROM; 

DFC  1ST  *N  s P"  A 0 A P'_ S C F E r. i IL E ,->«»p R I r1  P I T I 7 a t j*a. 
or  in  in  at  jn(;_RE  s i j I b e f F p t : 

T l S_DPSPP->pARAGRAPH-3_?_?_A_FiJ'.,rTlf,f  AL_Rf  Q lJ  I R E l-'  F NTS 

gpinpiA  r i”f}_RErJuiPEFF~T” 

Tl  S_DpSPR_F  A-?AGRAPh.3_?_?_.3-FIJNC  T T 0 i A L_R  f QUIRRRF  NTs 
OR  ir.iMAT  i”g,jE.JII  I Recent” 

T | 3„DPSPp_rAPAGR  APh.5  ?-2_C_FiJMrT  TONAL_RE  GUIREPENTs 
OP'  I G I n A t i”g_RE  SU I wEf  E~ tT 

Tl  S_r'P3PP'_PA  TAGRAPH-3_?_2_P_Fij'.CT  I "NAL_R{  QU I REGENTS 
OR IG I N A T ^F  QH  I c E R E N T~ 

Tl  S_DPSPP_P  APAGR  APh_  3_?_2_E->FIJ-JC  T T pn  AL_RE  GL  I WF-FF  NT  s 
OPIGIMAT  i”g_RE.U'I°e”ent” 

Tl  3_pP5PR_P  A R A G R A P 3_?_3_l)_FUMf  T T '“'N  A l._P[  G b I RE r' F f. T S 
OP  I G I N A T i”g_p  EG1  1 1 hE~F ~ t” 

T|_  S_r'PSPU_P  At?  A GRAPH.  3_?_3_E_F'»N'r  T I **'  AL_R{  Ul:  I PE  FfA  Ts 
OR  I G I N A T I NG_RE  GIJ I P£  ► F~  T~ 

Tl  3_r'PSPP_S'JnSEC  T I ijP_3_?_?_rilNCT  I fl  < A l_REgD IPEMEK TS 
OP  I G I M A T J N G«  R F ;T  IJ  I R £ D ” NTS_ 

Tl  S_l)PSPP_s|l^SEC  T I M _3  2 S.ruNCTIOhAi PEr.UIRE*EMS, 

ST°UC  Tl'RF ; 

a i p p a j sfl  rc  t.C'fvami 
if  (RECOF'f'.FO'J'n.)) 

alpha;  ”p iC^^C O14" ap I.' 

F V F N T S X t? J 

r o N s I i ’ E p 0 A T A s P A 0 A T V P F 
I F ( T 3 ) 

A L F h A ! FOpv_T3 
OR  C T 1 PR  T <?  ) 

A L f h a : F"  ?‘'_T)_T2 
E 

VALID  AT  I o n_  P ' I NT  I PAPAp.COHMANU.OUTPllT^POINT 
c* JTPHT_J  ^TFRFaCE  I PAPAR~fll  T 
OTHER*  I SE.” 

EVENT;  SChEOULE 

TERMINATE 

E f 0 
END, 
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SUBNET;  r XT*f&C7_‘t  iS'jPE'if  NT  , 

ImPLF  mF  'ITS  t 

vF  v s I "tij  P^L^_CCMPlLF  P_l  T m I T A T T P r _C  n *’P T f S A T I .>r. . 
REFERS  t*s 

ALPHA!  Sf  T_ P'JLSE 

A l Pmaj  11_T2_-T  ASuRrMFM_EYTRACT  T O' 

alpha:  i 5^‘  f ASl'KF.Mf  * t_ExTRACTI«f 

DATA;  TI"AGE„Il> 

DATA;  TA»GF7_ID 
E f tity^c las>!  image 
ENTITV^r l*SS:  PULSE 
EUTITY^typE  : LnST_(- i>lsE 
ENT  I T Y_T  YPf  : PF  TU«I  f r_PLiLSE 
ENTI  TY~T  > t'E  : M.T2„P|“Sfc 

ENT  T T Y_T  YPE  : T 3_  Pljl  SF  , 

RtF£PRFi)  by; 


P_jFT!  PF  Sr  v-sF<_Tf?^PADAB, 

STRUT TURf  : 

SFLFCT  F"  T ity_CL  4SS  J IMAGE  St  'C  ^ THAT  ( I m age..  I Us  T ARGg  T„  in  ) 
c f*  N S I U E R i ' TTTY^CLASS;  PuLSF 
IF  (T3.PULSD 

ALPHA  ; T 3_  * E A S lj R E n F NT_t  * TRAC  T I (IN 
PE  t T 1_Tc'_P"l  SF  ) 

ALPHA  ;”  T t_  Td^l  a SLPF  I^F  r:  T__f.  XTWAC  T I o,v 

CP  (LftST— Pi'LSE  V RFTl  RNrr_PUl  SE  ) 

EKT 

ALPHA:  SF.  T_PUlSE 

RF TURN 


EnO, 


SUBNlT?  F3R'_FPA-t. 

DESCRIPTION:  "FftR:i_EPAME  PR"V]DES  RapaR  Cd'FllCT  NESCLUT  I ON  , " , 
REFERS  TO; 

A l Pha  j v Imu_Co' FL  IC  T 
A I PH  A J MAKE^CoMflA^r 
A l pha : SF I_L A3T 
DATA.  r A'-PlOATf  _HAr,F.  I 0 
DATA;  npop^FL AG 
Data;  I U(.;F_Ii; 

Ef  rTTY_TYP|_:”  r'AGt_IN_Tf,  ACK, 

TRACFD  FRfU'7 

OBIGJNAT  I Nl,— ME.  QU  I P^F  F.NT  t 

IL  S^DPSPP.PAPAr.P  APH.J.P.a.A^FUMr  T I 0T  AL_PF  QUIR£MENT  s 
ORIGIN  AT  I NG^KEiH1  I RfF  t K t7 

Tl  S-DPSPR-(r,APAGPAPH_3_?_t,.B_FUNr  TICNAL^RF  QUIRE RENTS 
ORIGJNAT  l”(3— WE  QU I Bt  E Fat” 

II  S_DPSF'R^F-ARAr,RAF>M_3_?-p_c_FUMrTI0i-'Al _RF  QLIWERfNTS 
ftp  I GIN  A T 1NG.PF  iU'1»E^E  NT  : 

TL  S.DPSFP.F’ARAgR  APh.3_2.2_D»FUMCTI  on  aL_»F  RU IRENE  NTs 
OP  IGInat  Ing.pEiJUIRee  FM  : 

Tl  S-DPSPP_PARAGPAPH-3_2_3-n<_FHMrTloK  Al_REQl  IRE^E  NTs, 

REFERRED  BY! 

R.JFTs  SKED.R, 

STRUC  TURF  J 

At  PHA;  FIND  CONFLICT 
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If-  (NOT 

ALPHA?  M7Kfc.Cf,^"1Af>n 

SELPET  PINT  I TV— Ty  P£  j I H A Gp  _ I N—TP  A C K SUCH 
f I lu,AGE_jr  = C A NPTO  A yf  _ i ►‘Af,f-_TD) 

( *MJSl”i,i>LCfctO  S I NC“  SUtCTEO  ON  CALLING 
alpha  • St  T^L  AST 
OTHP  P* I St 

ET  0 

Pt  TiRN 
END, 


<■  F T * j 


SL'fcfN  E T • HlSSIf,r,_wt  TijRnS, 
RtEEPS  Tn? 


a i pha  ; 
data  ? 

DATA; 


SE  T„L  * S T 
PEEP  1 vE_ST"p 
? T ^P_  T I 'i 


EN  T T T Y— r L A S P>  ? P'JLSt 

TIT  Y„  TYPE:  LrtST_nn.SE 
ENTITy“t  YI’P  ! PE  T ' l”  r-  r D_Pl'LSE 

Ektity”typt:  T1_T?_pi”se 
tN  E I T v”l  YPE  ? T 3_P(jl.  SP  , 

TRACED  from; 

OR  [ r,  I A T I ' ■ P E 1 I R £ f f NT  J 

TL  5_PP?Pk_R  APAGPAPH_  S_p_3_F_FU,'irT  I '"NAL^PpGUlPE^E  NTs, 
REFeFPPd“by; 

r_net?  KtSpfl,'SP_Tn_PAn  ar  , 

STRur  turf . 

CONSIDER  ENTTTY_CLASS:  Pul-SE 
IP  C T t_T2_PULSE ) 

TF  “fit  re  T vE_S  TrP<sT  *P_T  X ME  5 
ALE  ha?  SP-T_L^St 

0 THP  pH  T SF 

f sr, 

OP  (T3_p|jlSP') 

TF  “pete  T VP:_S  TOP«sT  f«p_T  I^E  ) 

ALFha?  SE  T_l  f,S  T 
« The  pi-,  j st 

F Nr 

OF  tL"ST_PULSP  *p  PETIPNFO  PULSE) 

END 

Pf  Ti  PN 
END, 


SUBNET?  PECOWP^I  pop. 
refers  T^j 

A|  Pha  ; SF  T.  TP  OP 
EN  TTTY_Cl  ASS?  I'-AgE 
ElTlTY^TYPt?  n»oPpEO_IPAGE 
ENTITY” TYPE?  I * AGf_ i”  twacn 
EVENT?”  ALLOCATE, 

TRACED  FRO«? 

OP  IRJNA T ING.PEauIRE^FNT I 

T l S_pPSPP_P  apagp  aph_3_P->S-H_P  U 1C  T I OH  AL_«t  GUI  REGENTS, 
REFpF  pp  o‘bv, 

R.NFT?  CC^RESPONSf 
w”net»  wt  sPTNSE_To„«AnAp, 


ST&uC  Ti'RE  s 

CC'ISIOE'’  T!  TV^CLASS!  Image 
If  ( I ■>  a r.f  _ i ._t  i*z*) 

JLPHji"  SEt_'P|*p 
fvf'jrt  4i.L~c.irt 
PR  C.)RpPPFL'_I''AGE) 

END 

RE  ft  Sn 

EnC, 


SUBLET:  s JM_CETUR'iS, 

REFERS  T * s 

A l P h 4 j p p * c o c L S E 
alpha:  SE  T _ 5 J E'T 
At  Pm  a s S11-  _ <3aCE 

P A T A : ACCfU  'TEr_FpR , 

TRACED  pup':: 

ORIGI'-AT  I '-r,_JE  lUIREyE  NT  t 

TLS<_OPSPR_RAPAgRaPm_3_2_u_a-FU''ICTIONaL_RF  UUIREhENT$ 
PRIGJNAT1  »C-»“£  >u  I “ E y E ~ T : 

Tl  S.nPSPR.P-'  JAGR AP„_3_?-S_P_FU'ir TI«‘ial_RE,.uIRF>  ENTs 
aRIGIMATjvG.RE  Tl  IRfA  E~T~ 

Tl  S_PPSPR_SL'MSECT  Ion_5  ? R_F|jNCTI  On al_rF  f,UlREuENTS. 
RERERRP 1 Rvs 

R_NETj  RAI.AR_3U«“aR  y , 

STRUCTl'RF  : 

CONSIDER  U A T a j ACCOINTEC  FJR 
IF  (COUNTED) 

ALPwAi  S'JM_'JSAGE 
alpha:  npAP.PULSE 
PR  (nEIThfw) 

alpha:  Sl'VJaAGe 
alpma:  $E  T_S(JmhEo 

PR  ( 3UMF-E  0 ) 

£T  D 

RE  TURN 
ENC, 


SUBNET:  TALLT.RETijRr.S, 

REFERS  f * ; 

AL°ha:  pRpP^PjLSE 

ALPHA:  St  t.CVnTED 

*LPwAJ  S'P'.ENEPQT 
DATA;  A c C r 1 < T E C_F gR , 

TRACFD  FR'M. 

PR  IG I NA  T I ’<G_PE Tl  I«e;4  F*  r J 

TLS_DP5PH_PA J4gRAPh_S  ?_u„.A_FUMCTl«NAL  Rf.GUIREHENTs 
PPIGINAT  I-'G^’E  j i I “ E 1 E ~ T I 

TLS_f)PSPR_S"RSECT  Ijn^J  ? u F UNC  T I N AL_REf.U  I RE  MEN  TS  , 
REFERRED  BY: 

R.RET:  C'nIRPL-SEsCUBCES. 

STRUCTURE; 

CPnSIDER  DATA:  ACCpLNTF  G_F  PR 
IF  (StJHMFPJ 

alpha:  SU”_E\ERGy 

alpha:  r,R‘P„P'.'iSE 

OR  (NEITHER) 

alpha:  su'-'.Energy 
alpha:  St  T— c PUN T EC 
OR  (COUNTED) 

EM3 

RE  TURN 

EMC, 
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APPENDIX  G 


TLS  REQUIREMENTS  NETWORKS 


4 ' 


co  -o  O)  cn  lo  bo 


CC  ..RESPONSE 
STRUCTURE  LEC-ENC 


NODE 

10 


1 


OROINfiL 

VfiLUE  CONDITIONAL  EXPRESSIONS  AND/OR  COMMENTS 


l HflNCOVER  _I  MPC-E  ) 
l INITIATE  _ENG-GEMENT  JIQDE ) 

( TERN [NATE  _ENGAG£N£N  T J1JCE  ) 
I0R0P_TRRCK ) 

ICCJ1ESSRGE  .ERROR) 

I [MRG£_SC-HO_iD  j 
l FOUND  ) 

OTHERWISE 


RESPONSE  _fO  J?90RR 
STRUCTURE  LEGEND 

nooe  ordinrl 

ID  VALUE  CONDITIONAL  EXPRESSIONS  AND/OR  COMMENTS 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
1 1 
12 

13 

14 

15 

16 


( PULSE_IO=RR_flROER_IO  i 
(FOUNO  ) 

OTHERWISE 

( RAOAR  _TYPE-PULSE_TTPE ) 
OTHERWISE 

t PULSE _SOrRR_QRQER_ID) 
l VAL IDJTETURN ) 

OTHERWISE 

I LOW  _£LE V AT  ION ) 

OTHERWISE 

1 [MAGE  JIO<>YARDET_IQ  ) 

( I MAGE  _I0= TARGET  _IOJ 

i reoundant_;mage ) 

OTHERWISE 
l GHOST_!MAGE ) 

OTHERWISE 
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best  available  copy 


U7K3 


SKED_R 

STRUCTURE  LEGEND 


NOOE 

ID 


1 


ORDINAL 

VALUE  CONDITIONAL  EXPRESSIONS  AND/OR  COMMENTS 


I ENGAGED ) 

(STANDBY ) 

( LAST _PULSE<-(  l .O/TRACK _RATE)«TEOF) 


g u Btsi  Available  copy 


•uujpo 


X M I T F 

STRUCTURE  LEGEND 


NODE 

ID 


1 


0R0 I NRL 

VALUE  CONDITIONAL  EXPRESSIONS  AND/OR  CONNENTS 


(RECORD _FOUND) 
OTHERWISE 
I T 3 1 

(T1  OR  T2 ) 


^ UJ  K) 


FORM_f ROME 
STRUCTURE  LEGEND 


NODE 

ID 


1 


ORDINAL 

VRLUE  CONDITIONRL  EXPRESSIONS  PNO/OR  COMMENTS 


(NOT  OROP_FLRG) 

OTHERWISE 

(■MUST  SUCCEED  SINCE  SELECTED  ON  CALLING  NET* ) 
( IMRDE_IO=CRNOIDRTE_IMRGE_ID  ) 


AD-A046  571 


UNCLASSIFIED 


TRW  DEFENSE  AND  SPACE  SYSTEMS  GROUP  HUNTSVILLE  ALA  F/G  9/2 

SOFTWARE  REQUIREMENTS  ENGINEERING  METH0D0L06Y.  SREP  FINAL  REPOR—ETC (U) 
AUG  77  M W ALFORD » P H BROWNE#  I F BURNS  DAS660-75-C-0022 

TRW-27332-6921-026-V0L-1  NL 


ADA 


£ 


046571 


I 7TL  '<  ( ?UTP!l  r , * f VIM  A Jf)_/rfAvEFl*B^-<  (.(V.H4  jp,  i«  a V f F cuv  p ) ; 

XR  ! T 1 1_ ^ ( flUl  Pfl  T , ' r ,'r!M4».ifi_E.N,f. O^Ys  • , C ty-'M  and  f ~ t-  W C-  V 1 • 

wsiTf  ln(«utput,  • aTA^r^ ti~*c=,,5ta«t 

t*R  I TUN  (OUTPUT  # • 1ST*', 1ST); 


SUM  _RE  TURNS 
STRUCTURE  LEGEND 

NODE  ORDINAL 

ID  VALUE  CONDITIONAL  EXPRESSIONS  AND/OR  COMMENTS 


1 (COUNTED) 

2 (NEITHER) 

3 (SUMMED) 
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APPENDIX  H 

TLS  REQUIREMENTS 


ALPHA:  Af*f.T*LFPGE  , 

Bt  T A : " BEG  I f-  ENDS". 

FORMS : 

-1  E 3 S A Ci  t : A C K \ ft  * L F P ('  E.  f ' F f'  T . 

RtFEP^FP  B v : 

R_NE  T : cr_RE.SPflr.SE, 

alpha:  assign.rate, 
beta: 

"BEGI  >1 

SELECT  FIRST  KEC^rP  Fpfy  sTATt.FTLF 
SUCH  THAT  (S r ATE_lOsI maGF_IP ) I 

track_watf j=state_pata; 

WR I TELN (OUTPUT, ' ClOCK.T I"Er ' ,f  l nfK_T I me  5 » 

WRITFLNCOUTPI'T,  ’ TRACK.  MATE  s ' , TPack“waTE  ) J 
END}", 

Inputs : 

DATA;  IHAGf.I'l 
FILE:  STATE.FILE, 

o u t p i rs: 

DATA:  TU ACR^W ATE  , 

T K A C F D F M « M { 

■TPir.iNA  r ing.weijI'IWe1  f>t  : 

Tl  S_DPSWW_P  AW  4&WAPm_S_?_  i_i)_F'INC  T If”  A l _ w I Gil  I RE  F-E  N T s 
OPIGINAT  1 W t 0 U I W E H E N T : 

T L S_l)PSPk_P  A w aqR  aPh_  S_?_.J_B_FUMCTl<ir  Al._kf  GUI REGENTS. 

RE  F£PkE  ) BY: 

R_>iPT:  C'”|TPr’L„WFsPuRcT  S • 

ALPHA  : cr_f  «p_pr  Mf.E  SS  I nG  , 

beta: 

"bet  If 

ESP}  " . 

RE  few  we i)  by; 

R.vET:  CC_RESPf,,SE. 

alpha:  cohple  tf_suvi' ary , 

beta  : 

"BEGIN 

pat  A_RfcPk u_ type :=wapaF_ls4GE_pEP art ; 

EflCAGEMfcNT.TlHF  : SCI  OCk. TIME} 

*RITHN(«UTPUT,  • c7mCK_TIhE  s • ,CLfCK  T I Mg  ) j 

HRI  T { LN  ( OUT  Pi1  T i 1 P ATA  J.'E'C  iPp.T  YPF  = ' 7^*  T *_RE  C ORf>_T  YPI  ) > 

WRI  TELN  (OilTPU  T , ' ENGAGE  4*  nT_T  j PE  s • , ENGAGE  TFNT.T  I M£  ) ; 

ENPJ  ", 


FORMS 


MESSAGE:  rADAR.USaCE, 

INPUTS : 

DATA:  CLfiCK  — TIMt 

DATA;  R aDaR.ClOCK , 

outputs: 

o a r a : hat  »_PFc',pn_>T  ypp 
u a t a ; engagement  .7 1 m E , 

THAfFO  from: 

0PI(;iNATIM(,„wE(lliJf?EMFNT: 

TL  S.PPSPR.PARAgRaPh.  i_?-S_D_FtjHr  Tl0NAL_Pr  GUI R£ME  NTS  « 
pefeprfi/”by  : 

R_'JE.T:  RADAR.SUMMaRY, 

At  PH a | CPEA Tf.STATE.F ILE. 
reta: 

"BEGIN 

CREATE  state. FILE  PEC3FDJ 

STATE. IDjsImagF.ID; 

STATE. PaTAjsS! ATE; 

WRITE  LN  (OUTPUT,  * f L ’Cf.TlMEs  ' ,CL0C‘_TIl‘t  I J 
WRIT  F.  L N ( PI  u T PUT,  • STATf.IOs' ,STATF_l“); 
w'RITELNCOjtpit,  • S r ATt.OATAs  I ,ST  ate.  Data); 

end;". 

INPUTS: 

IJATA;  I-i  AGE.  TO 
DATA:  STATE, 

OU  T PI  Ts: 

FILE:  ST  A TF  . Flit. 

TRACED  FROM; 

ORIGIN  ATI  NG.PE  iJG  I RfF  E N T : 

T l S.nf'SPP.P  ARAgRaPh.  }_?.«.R.FU  TC  T I ON  a L.Pf  UL'IREE  E NTs  , 
P E E t R R E d”  B Y | 

R.^ET:  C’eiTR'IL.RF  Sf'tiRrE  St 

alpha:  DRTP.nsT, 

BETA:  " TE  G I N L'NI'J 
gamma:  "begin  Err"}", 

DESTROYS t 

enmty.class:  pui  st  . 

T R a c F 0 from: 

ORIGIN  at  I ig.REIUIRee  F N T j 

TLS.DPSPR.F-aRagP  aE’h.  S_?_<4_B.FUNCTI  OE'AL.RE  EJU  IRENE  NTs, 
REF  t FRF  1 H v : 

R.oFT  : NT RE  s M. i c r. f.  s. 

alpha:  uP'Tp.pui.sf, 

beta:  "BEGIN  E >10;  " . 
n E S T F TyS: 

eintitv.class:  pulse, 

TRACED  From; 

ORIGIN  AT  IN  G. REQUIREMENT: 

Tl  S.DPSPR.E’ARAGPAPh.  ?.  '4  . A.  E'  U N f,  TT0KIAl.R|  GUI  REHt  NTS 
OPIGINATING.REgUIRemFntT 

Tl  S.DPSPR.PARAGR  APH.5_?.N.D_FUNr  TIOf-AL.RF  UUIKEHEMs, 
REFEPPf/’hy  ; 

• subnet: 

Surge t : 


J 


SU*. RETURNS 
T ALL T.RE  T ijP  NS  , 


8ESTAVAIUBIi.CC 
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A l PH  A * EfJGAGEMF.NT_luT  TI  aTJOn, 

BETAS  "BFGU  M«.pf:s=tSGAGEt>  END  > " » 

OUTPUTS  S 

DATA*  m n I > E « 

TRACE  D Fw^mj 

OP  IG  I *1 A r I I WE*"  F NT  J 

T L S_D‘’SFV_P  APAr,PAPH_3_2_  1_A_FU  -1C  T T OMAL_«f  QU I REMF  NTs , 

REF  fcpRF  0~RY ; 

R_'JCTs  CC^ESPONSe, 

alpha:  find^conf lict. 
beta: 

"BEGIN 

OPPP_FLAG  S = F AL^f  J 

for  each  c*m>* an i’*  RECORL 
SL  C M THAT  (ST  APT_TIM£>Tff,F  ) 

I'P 

BEGIN 

lagssTpijf  ; 

';est”mv  ca  'inmATp  pfcopdj 
E N 3 s 

HRl  TLLNEOiiTPtlT,  • C t op  k„  T T ^E  s • , C L Of  K TIME); 

WHI Tt IN (OUTPUT,  • S T AP  T^T I Mf  = ' , ST APT“TIME ) J 
WRITFLN(0UITPUT,  ' TE'TFs  ' , TE«F  ) ; 

ENPFPRE  AC*' 

ENC; ", 

DESCRIPTION* 

"COMPARES  TRANSMIT  PpCtTVF.  MMi''*'  OF  The  CANDIDATE  upH 
th'isf:  "f  the  r h e t ■ _ c i t f p t n t command  fop  conflict,  if 

a CONFLICT  IS  Fol”n  DPOP_FLAG  IS  SF  T T R U F.  , " , 

INPUTS J 

DATA;  START^TIME 
DATA;  T E o F . " 

OUTPUTS* 

DATA;  OP'1P_FLAG, 

TRACFD  From* 

OF  CT  SI  ok,  ; TRAC  K_PeFFOPMaNCF._  ALL  OCATIOn 

0 R I G I n a t I N G„ R F.  ••!  U I P E M F N T I 

u S_DPSpR_PARAGPAPh„3_?_(?-.i3_PF  PF opm a NC E.F EG U I Pfc> E N T S 
OR  I GINA  T ING_WFGUI«Ef/E  NT* 

TLS„nPSPP_PARAG«APH_3_?_3_t_FIJNr  TTONAI  _R|  «u  I FEME  NTs. 
pefefRF^  by: 

Subnet  s mp^fhawe, 

AlPHA*  FORMAT 1_T?, 

BETAS 

"BEGIN 

t1.T?_tra>  s m I t : s o , o ; 

CREATE  T 1 _T  t?_G  ATE  RECORD; 

T 1 „ T ?_G  A tF_o  * T A S » 0 , 0 ; 

RfCE I YE_ST“p  ssTRANSMI t.st  apt; 

Tl_r2_XMiT,SN.i; 

cpf  ate  loow  Record; 

T |.T?..IIM  r)«J)ATAs=0,OJ 
WR1  TELN  (OUTPUT,  • C l.  of  k,  T I Mf  r • ,(.L  i»cK_T  I M£  ) , 

WR I TELN  OUTPUT,  * T 1_1  2_.TR  ANSmI  Ts  • , t7«.T2_TRANSN  I T I ; 

WR1  TFLN  (Out  PI'  r , • T I^Ta.GA  TF^DaT  As  t , T I _ T 2_G  A T E_D  A T A ) ; 
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WR  J tf  IN  (PuTP"  r , • 1^.  Cf  l^E.5Tnps  » #KFCF  I vP_STftP  ) ; 

WRIflLK  (flijTPtir  , ' T Ts ' , ti_t?_<mit ) / 

WRI  Tt  IN  (OUTPUT,  ' T 1 __  T c’—  R I \D ft  w_!J  A 7 A =”  , T 1 _T2..W  T N«>0  +J'  A T A ) > 

L ^ il  * • 

F ft  R M ? J 

■H  SSAGf  J r ANP  , 

INPUTS J 

GA  r A ; Tl/  A'.'S  < I r_ST  aF  t , 
ft  u T p i r s : 

.MTS!  RfCE  WF^STftp 
data:  transmit 

Data;  u”t2_<MT 
F U.F  : t i^tp^ga  T£ 

ftlf.:  tiIt2.kin.)Pw, 

StTs: 

EF  r J T y_t  YPE  : ri_T2_PuiSE, 

TRACFO  F R ft  M } 

ft  R I G I M A TI'iGJF  J l1 1 R f F F.NTS 

1 1 .S_DPSPR_PAR*GR  APh_3_?_?„C..FIHC  T Iflf- AL_Rf.  QU1REMENT S 
ft R I G I N f T I iG— RE'JU  JReFENt” 

Tl  5_I)PSPR_P  ARAgRAPm.  3_?_3_E_FNfJr  T t ftNAL_Pt  Qt'lHEMFNTs* 

refeprfo  ry : 

R_NET:  ft’HJ, 

ALPHA  t FftRU_T3. 

PET  At 
"BEGIN 

T 3_tr  ams’i  i t ; =o . > ; 

Create  t3_gate  record; 

Ti.GA  TF.OATASsP,  ; j 

t i_ xn- It  : = i .ft ; 

RtrE[VF_5TftP:sTRANSMTT- START; 

CRFATE  Ti_*lN|)ftR  RFC^RCl 

T 3„.*T  xnn^oA  t a ; n) , n ; 

WR I TEL  M ( 8 UT  Pi  I r » ' CI.TCK_T  HE=  ' ,ci  ftf*  TIwt)l 
WRITELM^UTPUT,  ' T 3_T  R A gS  « I T = 1 , T 3 TRANSMIT); 

WR I TF  LM  0 jTPu  T , ' T s~r,  A TE.O  A T As  ' , T 3_GATF_nAT A ) ; 

WRlTELMfiUTPi'T,  ' T3“y-',I  rs  » , T3_X^ir"; 

wr  mo  (Output,  ' ff"f i m'e.stmps ' ,RFCEWF_STftP); 

WRI  TF  LN  (ft'jTPli  r , ' T 3_A  W^PA  t A s ' , T 3_W  I NOftk'^D  A T A ) ; 

end;". 

F ft  R M S l 

MFoSAGF:  T3„C ft^MANC. 

INPUTS! 

DATA;  TRANSIT T.STaFT , 

OUTPUTS: 

data:  r f r t.  t v e _ s t ft  p 
0 a r a j t 3„tra‘ismi  t 
data;  t 3_x'A I t 

FILE:  T3.GATF 

FILF:  TS.^TxlOfJw, 

SETs: 

ENTITY.TYPf:  T3_PulSF, 

TRAcFO  F r ft m 5 

ftRIGINAT  INf,_RF  3UIREFF.NT  t 

Tl  S.OFSPR.P  ARAGRAPHta3_?_2_C„FUNr  TIONAL_RE  GUIREF'ENTs 

opiginating^rF  jui  Ref  F.nt7 

TIS_DPSPR,PARAGRAPh_3  ?_3_E_FU»C T I ftN aI  _RF  GUI  REGENTS, 
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REFERRED  by: 
w Mr  t : 


< ■'  I T_('  ♦ 


ALPHA:  pr  RH.IJPUATE  , 

ftfcTAJ  ">AF(,1N  i:  A 1 A_-'FC'lPo_T  VPf.  : =ST  A T[:'_llF:'A  Tf-_K  [ PfR  T LM!I", 
F 0 R « s : 

message:  b1  ATF^ijPnATf  , 
outpltss 

p A r A • |)  a T A. RE  c ORP_T  YPF  , 

T K A C f n F n A M ; 

op  I G ] u A T I 'IG.RE  NU  1 R t f F a T : 

U S.pPSP  !,’_P  A l?  A GW  A P h.  3_?_t>_C_F  H Me  T T ON  AL.Rf  UU  I RF.ME  N T S , 
R E F E (•  R r ) ><  Y ; 

<_  JF  T : '?F5p  Tr>»P  adAr  , 

alpha:  r,H«ST_PFTF  p-ATp^, 

beta: 

"HE  GIN 

G H A 3 T ^ T h A G F : s ( R A I i A R—  M E 4 S L1  R F F N T > = 1 a t O ) ; 

wri  tlln (Output  , • ri.  oc*.t  I u = ' , ci  or  *_T  ime  ) ; 

wRITt-LNC^uTPl'F,  ’ !.'  Af.jAR_-it  ASljRf  f-A  Ms”,  R AOAR_Mf.  AS  LIRE  fU  NT  ) ) 
writfln  (rtijTPu  t , 1 Ghost^i  'age=»  , GhiSt.I’-age”  ; 

end; 
input  3 : 

0 A r A : « ADAR.Hfc  ASIlRf  “fuT, 

outputs: 

Oata:  ghost_hage, 

THACFD  FRBMJ 

OF  C I S I P N ; TRAC^PE^FOPHaNCF..  ALL '’CATION 
0 P I G I N A T I N G.  R t U U I P £ *-  f Ni  T : 

T|  S_nPSPR_UARAGRAPH^3  ?_^_B-FUNrTTO,JAL_RF  OUIKF.mFNTs 
OR  I GIN  AT  I ”g_RE'3UIPe~Em7 

Tt  S_OPSp«_PARAGP aph_3  ?_2_B.PERF0RHANCE.REGUlRt>ENTS 
ORIGINATi“g.RE  juiwe^ent" 

T l S. t> p S p w.F  a p a i; p a p h. 3_?„3.C_FUNC T I ON AL.Pt QU I HEME NT S 
OR  IGI  ''AT  I'.G.RE  JUI»E^E  nt” 

TL  S_DPSPh'_PAPAGR  aph_  3_?.  J.G.FUNC  T I ONAL.RE  UUI»EHENTs 
OP  IGI  fJAT  I'iG_pF  JUIBeue”t7 

TI.S_OPSPR_PARAGRAPh_  J_  S.B.F  UNT  T I ON  AL— Rfr  QUIRE* ENTs, 
REFERRED  by; 

R.-JETt  rESp0,',3L_T  radar, 

alpha:  ghost^terhinat ion, 
beta: 

"BEGIN  CRFATE  terminator  » e.  c n r n ; 

HO.IDtsiHAGE.in; 

R E A S 0 N. F 0 R^DR  o P ; s GH  O S T J 

drop.hEason:sghost: 

TIHE.of.urop  :sf.L  bck_t  i^e  : 

C ATA.REC  ORC”tyPE:sTR  AC  k"teR>1I  NATION  WE  PORT  I 
DROP_TI”f  :=CL0CK_TIHF  ENf;;", 

forms: 

me3Sagl:  iwack.tfrh inat j on. 

Inputs: 

DATA;  CLOCK. TINf 
DATA;  I'AGE. ID, 

outputs: 

DATA:  DATA.RECORD^TVPT' 


H-6 


DATA;  HT_lO 

DATA;  he  AS^  'J-FOk_dR'OP 

DATA;  T J ME.OF.OROp 

FILE:  TERMINATOR, 

TRACED  PRom; 

I G I'm  AT  ru^E.'Jl.'IRE^EM  J 

Tl  S_DP3PR_PARAGRAPH_3_?_2_rt_F<lNCTIONAL_RfcQUlREMtNTs 
9 R I G I n A T I t ■ i,—  R E (3  U 1 0 f f'  f N t” 

TL  S_.DPvSPk_PARAGRAPH_3_P_3.C_F  JNC  T I on  A L_Rf  T3U I R£MEN T S 
3PIf;i^ATI^G.wP>TUIPEf  £ N T~ 

TLS_DPSPK_paRAgRaPh„  3_2_S.n_FU'JCTI«A  aL_R£  UU I HEME NTs* 
»£FEFRFJ  rv: 

w_ Jt t s response.  i_»adap, 

ALPHA;  IMTIAUWF_SkFd_?, 

BETai 

"BEGIN 

T'EPF  J =CL',CK_Ti'"E*FPA -ie_«atF; 

1ST  JsCLOCK.T  I"'F; 

WRI  re  UN  ( TTUT  PU T , * Cl'1CK_ri'*E=',lLClCt<_TIME)  I 

WRlTELN(PijTPUT,t  T P A'“L_RATE  = ' ,FP  a^p”R  ATE  ) ; 

WRITELNCTUTPUT,  ' Tf-  'P;  ' , TF  *3 f-  ) ; 

WRI TELNCOUTPUT, i IRT=',lSr); 

END?  ", 

DE  SCR I p T I "N : 

"COMPUTES  the  TjMg  -if  The  fnD  of  the  C"RHfcNT  FRAME,", 

1 N P IJ  T S l 

DATA;  CL',Ck_t  ImE 
DATA;  FRA'<E_RATE, 

OUTPUTS  J 

DATA;  1ST 
DATA;  TfcHF, 

TRACED  From  j 

ORIGIuaTING-RFdijiReFEnt  5 

TL  S_DPSPH_P4RAGRAPh_3  ?_2_A_FUNC  T ION A L_ REQUIREMENTS 
np IGIMAT T~&_REGUIPenF~t7 

TL  3_DPSPK_R  ARAQR  APH_?  p_2_rt_FUNC  TII?NAL_RF  QUI«EMENTs 
OP IGIha TI\G.RFDUIWEf f”t7 

T L S_DP oRR_P  A 7 A G(?  APh_  3 ?_2_C_F UNf T I ON aL_RE  GU THEME  NTs 
ORIGIN AT InG.WEGUIReRFNT J 

TL  S_DPSPR_PARAGRaPh_  3_2_2_D_FUNCTI0f.  AL_Rf  Qu  I HEME  NTs 
QR  IG I u A T i”g_RE‘JU  l re^  E nt7 

TLS_DPSPR_PARAGRaPH_ 3_ ?_2_E_FUNr  Tl ONAL.Rf OUIREHENTs 

originati7g_reguipe7f7t7 

TL  S_DPSPR_PARAgRAPh_3_2_3_D_FUNCTI ONaL.REQUIREMENTs 
DPIGINATI'iG_REaUI»Ef  F 7 T l 

TLS_DPSPK_PARAGRAPH_ 3_?_3_E_FUNr  TIO N A L_ REQUIREMENTS, 
REFERRFD  BY! 

R_NFT;  SKED_R, 

ALPHA  ; L(*o_El.LV  A T I n,\_DE  TERMINATION, 

hetai 

"BEGIN 

L So.ELEVATI  VO;sCCLnCK_TlyF  -tNTRY_TIMF>FLF V A T I ON_L I ^ I T ) > 
CUPRF  '(T.ST  A re  ;sCURPEn“_st  ate  i 
WRI  TE  LN  (OUTPUT  , ' CI.OCK.T  I HEs  ' , C L'OCK_T  I ME  ) » 

WRITE  LN( OUTPUT, ' LOw.tLFVATinNS',!  o”_FLE VAT  I on  ) ; 

WRI TFLN( Output, • enth Y_TImE= • ,ENTPY_TIM£) j 
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i»R]  tun  (Output,  ' u t.v  amvi.limj  t = • ,f  i tvAtin^u  hit)i 
[Ml!', 

ImPjTS : 

data*  it_s tatf 

DaTaj  r l r V a fl  ”n„L£  * T T 

L'ATA;  m;  TRY„T£M£. 

* U T P i 1 T S : 

l)  ' T A • i |_  FT  v'  A T I A . 

TRACED  F R * ■'  5 

ORIGp  AT  I'l^wE'JU  IWf^'F  U S 

Tt  S_|'.RSP  ,_r AR  Ar,R  aPh„  3_?_2_C_F  UNc  T T ONAl  _R[  QUIREr  E NTs 

'PinpATj  ou i w t~ P “ tT 

! I S<J'>PS»R_P  AR  Ac;R  aPr.  5 p_2_D_F'INr  T I PM  A l._R£  QU  I Rf  RE  N Ts 
"PIGI  (iT  ing^rfuli  { Rfhfk t7 

T L S_DpSPR_P  AR  AGRaPh_  3_2_3_G_RI  'lr  T I O'  A L _ •? f Gu  I RF.ME  N T s 
fl»l”lGAT  i”g.«E'3UIWe”f~t” 

T L 5_nPSP»_PARAGR  A Rh..3_?_S_B_P  ‘.Nr  T I *N  A L_R[  GU  I k E i<F  N T S 
R t F t R « E D H V s 

R_Mff7  j RFSPO\SP_Tfl_RAr)AR, 


ALPHA:  Lf‘-'.FFR'"T  lATp  .i, 

beta: 

"PEGIN  r R F A T t T F R m £ U A T fl  R ReC^Rf'! 

ho_id:=if  a ge_ i p ; 

RE  ASON.E  PR_DROr  SsL**  ’• 

PROF_RE  APfi”:=i.r-u; 

T I y tl fi  r_r  R P P s = C u C K_  T I '• fc  ; 

C ATa_RECO  YPE  :=Trac*_TERmINAT  TpN_REP1RT; 

TRPP^T  IMF  :=CL*CK_T  I‘-’E  F NO  J " , 

FORMS: 

•MESSAGE:  TRACK.TFRl  I\aTiOn, 

INPUTS: 

DATA:  f L^C^.T  P’E 

DATA:  IMAr.F^I^, 

outputs: 

DATA;  OATA_RF.CORD_T  YPF 
DATA;  HO_£D 
DATA;  RE  AsOU_F"R_Df;RP 
DATA;  T r’E.OF^DRfip 

file:  teRr?  jaTor  , 

TWACFO  F R o 11  j 

op Igi\ating»wf.3uipe.pf.m  : 

U S.Dt'SPR.PAPAGR  aph_  J_?_2.C.FiJ  'JC  T I o N A l.—  K E QUIRE H F NTs 
fl  R I G I N A T 1 m (,_  p £ q 1 1 1 R £ ► Fkt” 

Tt  S.DPSPw^RARAGW  aPh_3_?-2„D_FU-)C  T I PUAL_RE  QUIRE  HE  NTs 
ORIGIN  ATI  »G— PR  QLi  I WfH  E N T J 

TLS-DP5pw-PARAgwaPh„3_?_‘,_B_FUNc.  TIOH  AL_PE  GUI  REGENTS  , 

RfcFEPHf 0 HY: 

R_NET:  Rl;SpONSE_Tn_R  AGAR  , 

alpha:  *ake„allocat i*u, 
beta: 

"VAR  j , ^,I;FL  T A^T  TME  :RE  Al; 

BEGI » 

0 El  TA.Tpif  •sCL‘,CK-TiMp-LA<?T  allocate; 

WRI TFLN (OUTPUT,  • CL  or k_ T I 'IF s * , C L or k-T £ M£ ) j 
wri  t t l n c Output,  • i>elta„tme=  • ,celta”tthe)  j 
KHITE L w ( o U T P l r,*  LAST_ALLOCATfcs*,LAST”ALLOCATE)i 


J 
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WRITHE  ( 3 U r P L'  r , ' fcnERGYa  ' ,E.  nF  Rt  YI  j 
LAST_M.L«rATElsCL'iCK_7l‘'f  ; 

WWITtll1  (OUTPUT#’  L4ST_All‘iCATfc3*,|/1s-  6L1-  OC  ATE ) ! 

If-  ENERGY  > f . (’  T h E n 

r e r- 1 m 

E jert-y  : sFi  t RG y/oe  l 1 a_t  > f » 

U H I T fc  L f C r U T P T , ' r ' : L R f > V s 1 » E N E k f>  y ) ; ” 

.1  J = (I  . 0 ; 

r OR  FAFH  5 T A T I L f RECORD 

Pi  *> 

J : =.!♦  I ,r; 

WRITE  Lf'lfUTPUT,  ' J = ' , J I ; 

r vinf  /,!<b  aCh; 

IF  J > O.f  THEN 
SET,  I*' 

v:=f.  iL"(,y/jj 

^HITtLf'-C^UlPl'T#  ’ v=  ' , v 1 ; 

END 
FLSE 
E MT 
EL5fc 

V : sTRACK__pA  1 F.  ; 

URITELMfiUTRl  T,  ' Vr'T/I; 

FOR  rACH  STATE.FILF-  RfCflRO 

ro 

S T A T E— r A T A : s V J 

WRITElMOuTPUT#  ' STATE _ii  A I a = ' , s T 4 T F_C  A T A I ? 

EnDFORF ACH ; 

WRI T ELM (OUTPUT, ' STATF^DATAs' # st  a tE_D at  a ) ; 

E m D i " • 

INPUTS  I 

DATA;  CLU*.TlMfc 
DATA;  FMPGY 
DATA;  I.  AS  T_  ALLOCATE 

file:  state.fue, 

Outputs: 

data;  f aif  rG  y 

DATA:  LAS  T.AILOC A T E 

DATA:  statF_oata. 

traced  f r o v : 

5F  I r,INA  T I.-.G.PF.'QIJI  «Ef'FNT  : 

T l S_C'PSPP_E'ARAGPAPh_1_?-3.0.FD  'ICT  I OMAL_Rf  OL'IRF.ME  NTs 
ORIGIN  AT  i”g_RF.')I.|IREFF  M J 

T L S_Df’SPR_f  ARAG‘»APH_i_?.«_P.PHNcTI(i^Al_Rt  GUI  REM  NTs 
REFERRED  BY: 

JF  T : COMTROL-FEsf URCES. 

ALPHA:  makf.C  OMUAijn , 

beta: 

"BEGIN 

CRF  ATE  COMMAND  RFCOROj 
COMMAND_IHAGE'_Ii>:sC  AN|)1datE_IMAGE_IO; 

Comb  ANo“n  A V tEOR’-' : sc  ANpl  F A 1 e”a  A VEFiTRH  ; 

c omma  no”f  f-  ERGY  ! 3C  AM)  I q A Tf_E ~E.  RG  Y J 
START_tTwE tslST } 

1ST  I s I S T ♦CELT  A T ; 

wri teln (Output,  • cl^ck.t imes • ,clock_t ime ) » 

wrI  tf  ln  (Output  , » c o m"* m>. p* ag ids  ' ,coMMANn_iMAGF_ir ) ; 


l*R  I T FLN  ( OUT  P It  T , ' r om>*a  a vEF  Crms  ' , C 0 >'  M 4 4 w A V E F o R E ) ; 

WRITtL^COUTPUT,  ' c ohm  AK'n_ENERGy  s ' , C e'-"- ANT)_F  NF  R(- Y ) ; 

WRITFL^(^UT^t-'T,  * START_Tr*Es' .START  T j m £ ) ; 

‘"•PI  TE  LfM  (OUTPUT  . ' IST=', 1ST); 

EMC,*", 

INPUTS* 

RATA;  C A N P I 0 A T E_  F rj  E R G V 
0 A T a : r a up  T D a t F_  I m a GF  _ T r- 
PAIAJ  r A'-t'  I II  A A VFF  OR  V 

j a r a ; n e l t a r 

DATA*  1ST, 

outputs: 

OAT  A;  C""'  HAUN_T  NErC-Y 
PATAj  p n !■*  ’ * A nJ  0 __  I m a (j  { _ 1 0 
DATA;  f 0UMAi\lD— wAVgE  OP*< 

OAT  A:  1ST 
0 A I A ; S T A (*  T__  T I M f , 

TRACED  FRO'*: 

IPIGlNATIUb.Pf  )U  I F £ f F N T ! 

T I S.OPSPR.F  ARAr.P  APh_  3_?_3_D_F  1 1 1C  TI  "NAl  ^P'F  UU  I REGENTS 
ORIGIN* T I -oG^RF  UJIHf^FntT 

TL  S_DPSnR_,JARA,;;RAPM_  I_?,3_E.FM'iCTTi'f  AL_»F  ROl  REGENTS  • 
referred  rv; 

S 1 1 *3  N F T : TAM  AMp  f 

alpha:  pick.cami'toatt-s, 

RtTA: 

" REG  IN 

CREATE  CA-.pioaTE  RFC^rT; 

CAKDJPATF.r'AGF^lOisTMAGF  Id; 

IF  *A  YEFORMsT  1 MEN 
PRlOwpvjsl.O 

else 

If  «a yffopmst;?  then 

PRlnRlTYjsa.i) 

ELSE 

PRIORI  tv js  3,  o; 

Cai  o I R a te_r a vt f or-ijswalfform; 

SELECT  first  PFCVD  FrC'1  wA vEFORM^TARLE 
SUCH  THAT  «F_NAMf =*aVFF ORH) 

IF  NOT  RF.C .AMD_F  TU.nIO  TufN 
C AND  IP  A Tf-  FNERCv:sO,0 
ELSE 

C ANOlpATF._FNKRGy  : = wf_CHaF  AC  TFR  1ST  ICS! 

wri  te ln (Output,  1 cl“o_tIhes  • ,CLor>_TiM£) , 

WRITELN(0UTP(IT,  • LAST^PHLSEs  1 ,1  A 5 T_  P " L S t ) J 

wr I tein (Output, » te  of  r 1 , t^of  j ; 

wri teln (Output,  * tractates • .trac*  fate); 

i«r I TELN( output,  * c anoioa  te_imaC  F_irs  < ,CANotnATF_TMAGE_iP); 

WRI  TELN  (OUTPUT  , * NAVEFf,RM5~,wAvtFi'Rh); 

WRI TEL N (OUTPUT,'  PRIARlTVs* , PRIORITY); 

wr  i teln  (OuTpuT,  • c a *ji>  1 1>  ate_*a  vE  for  »s  ' ,c.  and  in  a tf  _mave  f (;rm) ; 

*RI  TELN  (OUTPUT  , • CANUIOATE^pNtkGYr  »,  CANDIDATE  energy); 

end;", 

description: 

"Each  Iuagl_JN_Track-  *h!Ch  mIghT  generate  a message  THIS 
F p A u F MAS  ITS  Transmit  A No  RECEIVE  START  ANL  STpP  TI*ES 
EXTRACTED,  ITS  E^FRGT  demand  OFTFRMiNfp  A NO  ITS 


priority  established.", 

EnTeREO.HY;  "M,RTCmTER", 

INPUTS! 

DATA;  IMAGF^Tf) 

0 A T A ; A V t P >1 R M ** 

( * I\STA  .Cf'S  >E  F.  N T I T Y_  T T**E  I * A I N_  T R AC  K * ) 

F T L F ! ■<  A wf.F  "Rm_  T Apt  F , 

"UTPUTP! 

DATA:  CA’  l>II)ATf_f  (4fc«GY 

0 A T A • ( AM  TllA  T r_  I f,  A G F_  I D 

L'  A T A • CAUUinATF_WAVErrJr.M 
0 A r A J PPT.V<’ITy, 

traced  erv: 

Of  CTSKn:  S Y'.'CHfin^ClIS  V5_AS  YNCMN9M<*US_Tf  ACK 

trig i ^ a t iNG.tff.'OiJiWfcc  f.  nt  : 

T|  S_I1PSPP_PAW  AG»APH_5_?-3-r-.f'U  'irT  tCJHAL_Rt  UUIREMEMs, 
RE  PE.PNF  ,)”h  Y : 

R _ -'J F T ? Sk-fcP.R, 


ALPHA!  P T CK«C  f'MYM  :r- . 

HET  A ! 

"BEGIN 

TRANS'HT_STA«T!=START_TImf  ; 

K A r A P_  T Y <’  ( ! s c 1 ' A nP_  r.  A V E r " R m ; 

rr^opdfr^idc : sRR_NC?r'F  R_irr ♦ l » 
RR_OROFR”ll5j=RR-,,RPtR-lt'C  ; 

Pl.aSF.TYPE  jsCfl^  *4A'<D-^aVFF«R'''  J 
T ARGE  T__ I r ! rC^M  * A -J t>—  I M aCF_tT  / 

Pul  SF_I() ! sSk_nFrDE  R_If)C  J 
X^I T_ST  ART  j s”t ART_T I^e  ; 

Destroy  c f* m m a r-» 0 RECORD) 

HRITELMBuTPl'T,  • ClOCh^T  I ‘<Es  1 #Cl  *CH  TIME); 

KRI  TE  LN  (flUTPl'T  , « TRANSMI  T_ST  ArTs  • , T R A NS*  I T_S  T A R T ) } 
WRITtLNtOUTPl'T,  ' RApAF,_TY~F=  ' , F-  a r,  A R_T  Y PE  ) l ~ 
WRITELNE^UIPI'T.  ' RR^URf'EP^lOCs  ' , RP_~Rpf  R_ I DC  ) > 

HRI TELN  (PuTPi'T  , I f'f”npfiEP"ir)ai  ,rp  "pOER.Tc'); 
WRITELNtauTPUT,  1 PiJLSF_T  TPE  = ' ,Pi'L  SF  TYPE); 

WR  I TELN  (OUTPUT  , ' TAF.GE.T_  I us  ' , T A k GF  T~I  p ) > 
WRJTELMPUTPl'T,  • r i il  3[  . I Os  ' , Pul  SE  lF)» 
WRITELN(?UTP(iT,'  Xmjt_ST  ARTs  XmiT.,sT  ART) ) 

end;", 

OESCPIPTMNi  "t,IC«-CflM"Af  P SF  l EC  TS  NfXT  COMhafP 


CREATES! 

E m*  T I TV 
INPUTS  ! 

Data. 

0 A T A * 

0 A T A t 
E J LE  J 
OUTPUTS! 

DATA* 

PATAj 

OATAj 

DATA: 

L>  a r a j 

PA  TA  ! 
DATA! 
DATA  j 


CLASS!  PULSE, 

SHARPE  R_If'C 
ST  APT— T jf’E 
XNI T.ST ART 
Cf)‘1‘'  a JlJ, 

PULSE. ID 
puls*. type 

RA(jAP_T  YPt 
RR_lR|)Ek_ir 
o«_"»ROtff.IPC 
TARGET. 10  • 
THANS‘<t  t_st  ART 
XSI T.START  , 


t 


i 

i 

I 


H-n 


k 


TRACE  D F K n M } 

ORIGIN A TING.BF  t fvT  ! 

ri  S— l)PSPR_F  AR  AGR  aPh_  3_2_  3— D— F'J’JC  TIC?naL_RE  QH^fEMs 
PPIGINATING.PE  JUIReHEnt” 

TL  S_[>PSPP_PA»AGWaPh_3_?-3„E-.FUMC  T I.?*-  Al  _«t  QL' 1 RE«E  M$ , 
REFfcRREcTPYl 

W_'Jf  T : XMjT^R, 

ALPHA  ! PfOH'M^nf  1NAT  JAN  , 

BETA  : 

"Hf GIN 

«truf  1A^:T_TMA(;F;S(  (RFoLNnAN  T_IMAGt  ) OR 

C S T A T e schKrEnT_STa TF ) I ; 

WRITFLNteuTPUT,  • Cl  r HI  = 1 ,CL  PfK  TiMfU 
WRlTELN(CuTPUT,'  CUPPtNT.ST  A T f-  s • , f UrRE  H T.S  T A TE  ) } 

WRI  TELN  (OUTPUT  , > STATfcs  * , stat e ) I 

WRI  TtLN  (OUTPUT  , • Rf  1 1UM1AN  T_  ImaGEs  ' , RF  DUNG  AN  T..  I * Af.£  ) > 

end;", 

INPUTS! 

DATA;  rUPWCNT^STATE 

data:  state, 

OUTPUTS : 

DATA;  RE  T'iJNO  A M T—  I M A GE  , 

TRAcf J F R 0 m j 

DFC  t s I t’N : trac*_peRf  orh  a-'XF.ali  ar,  a t i On 

OR  I G I N A T I '<G— PF-  J"1RfvF.M  ! 

T L 3_nPSPR_PAR agBaPh-3_2_^_A_FUncTI ONAL^RT UlIRF.MENTs 

0 R I G I‘ i i T I ” G ..  R M U l R £ H f- ~ t 7 

T l S_DPSPR_PARAGRAPh_ 3_?_p_B-PfcRF op ^ANCe.R Ecu  I REPENTS 
OR  I G I n A T i”g— HE  UU  I he”f  N T~ 

T l S_[)PSPR_PARAGPaPh_  3—?_  3_B_FI|NIC  T I on  Al  _R£  QUIRE^E  M$ 
OF  I G I fi  A T I GG— RF  QU  I Re" F N t7 

Tl  S_[)PSPR_P  ARAGRAf;H_  3 ?_3_G-FUirTlONAl_R[  QUIRE^INTs 
OR IG1nATi”g_RKQUIRe"e Nt" 

Tl S_rP5PR_PARAGPAPH_  3 2_S_B.FUNc  T I on AL_RE GU I REHE N T s , 
RtFEPRN  BY: 

R_nftj  RESp-,NSE_T(i_RAnAR, 

alpha;  r f 01 1 n_  t e p m i ih  a t i o • i # 
beta  : 

"IIEGJN 

CREATE  TER  m I ‘J  A t *R  R'ECoFP; 

H0_in:sjHAr,E_lr'j 

TIfE_PF_OFrr:sFL''C*<-TlTt; 

GROP^TlMF-sCLPCK^TI^t; 

RtASPN_F  •R*_GRClPjs»FOIlNl  ANT# 

Crop_Rf  as*1”  : sreihmo  ant  ; 

0 AT  A~RF  c«Kri_T  YPt  : = Tw  ACR_TFRH  INA  T r ON_R'FPORT  ; 
HRITFLN(OUTPOT,  * C|.“cK_TI^Fs'#CLOrR  T I h ) J 
WRITFLN(OuTPiiT,  • HO_Tn=  ' #HO_To)  f 
WR I TELN (OUT  PUT,  ' T T~F— OF„0P”Ps  ' , T 1^1  _0F_r>Rap  ) j 

WRI  TELN  (OUTPUT,  * OR  nP~  T I = ' , ()R  or  Tj”e)7 

WRITELN  (OUTPUT,  • f-F  ASON_FnW..PHPPs“,  pF  AS0N-FOR_GR*'P  ) J 
WRI  TELN  (OuTPl  T , • (..RflP  reasons  ' *ORfP  REASo"l; 

KR  I TELN  (OUTPUT,  • [ AT  a“reC  TRUETYPE  = ' ~0  A T a_Rfc  0RI1_T  YPt  ) J 

end;  ", 

FORMS  I 

MESSAGE!  THACK.TE.RHInaTiOn, 
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INPUTS! 

DATA;  r.L*C*_T  I*E 
DATA:  Ir1AGE_lD, 

outputs: 

DATA;  r<AT  A_REC0RD_T  YPf 
DATA;  Hfl_IH 
0 A T A ; RFAS4'"J.FPH-OPPP 
D A T A j TIME„OF_D»*P 

FILE:  TERMINATOR, 

trace d fraim: 

ORIGIN  ATI  NU_RE  >3U  I R£H  E M ! 

TL  S_OPSPR_PAR ag^aPh. 3_?_2_A_FU  JC T I r:  AL_Rf  QU I RE ME M Ts 
OR  I GI NA  T I NG_REUU I REf  ENT~ 

TLS_DPSPR_rARAGRAPH.3_P_5.B_FU  >)C  T I ON Al,_Rfc  QUlREMEMs 
ORIGIN AT i”g.REUUIReE  Em” 

TLS_DPSPw_PAWAGRAPh_  3_2_5_R_FU  VC  TIONAL_RE  (JUIMpHENTs. 
R E F E P R F d”  H Y : 

R_NF  T t WFSD‘*'lSE_TO_RArAp, 

Al PH A J RF  Bf  MRER_STnP * 

BE  TA : 

"BEGIN 

STOP_TIMF.:sRECE.IVE.ST(?E  I 
xRITfcLN  (OljTPliT  , • CLOCK_T  T'Fs  ' ,CLOrt<_TIBE) ; 

wri  TELN(OuTRrr,  * stop_tp’es  ' »stop 
end; ", 

Inputs: 

DATA*  RtCt  WF._S  T^P  . 

0 U T P U T S : 

DATA}  ST"P_TI'«F, 

TRACED  FRftHj 

ORIGINATE: G. REQUIREMENT  ! 

TL  S_DPSPR_FARAGRAPh_ 3_a_3 _F_FU JCT I ONAl_KfcQUIREBE NT$ * 
REFERS  D~f3Y  ! 

R_  'IE  T : RESPTNSF_Tn_RAnAR, 

ALPHA!  RP_FRR9R_PW^CESSINGt 
BETA!  "BEG  I'  END;". 

referred  by: 

R_NE  T!  RF  SPO;isF_Tn_RAnAp, 

ALPHA!  SELFCT_C«^MAA'Dt 

BETA!  "BEGIN  SFLrC T EIRsT  RFCpRD  FR?m  roM*ANl>  END;", 
INPUTS! 

file:  comma, jo, 

OUTPUTS! 

data:  record.foijnd, 

TRACED  FROM! 

ORIGINAT  ING.RE:JI'IREhfkt  ! 

Tl  S_DI’SPR_PAWAgRAPh.3_?_3.D.FUNCTIONaL_RE  QUIREHFNTS 
OP  I G I N A T I NG.REDU IRE^ENT I 

TL  S_DPSPR_P  ARAGR  APh.  3_ ?_ 3_E_FU'JC  T T ON  AL_»F  QU IKEBE  NTs  * 
refeprfd  by: 

R_NET!  khIT_R, 

ALPHA!  SE T.COUNTED, 

BETA! 

"BEGIN 
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acc  nn^Tf jsc'jMf  d* 
rtRlTELNlOiJtPliT,  • Cl  -iCK.rlvf  s',CL'*C'<_tIwE); 

WRITKM  (Plit*»uT,  • ACC^U  TEP..F  ««  = ' , iCC^UNTf-  D_F  PR) ; 

EH'I  " . 

PljTpi  is : 

) A r A : ACC  *"J  lTEr-F  l*R  . 

trace  n fp**<  : 

P p I r,  I • a r i ',r._RE iji 1 1 R£.  p C n t s 

Tl  i.nPSP^^p  a-?agRaph_3_?_u_a_fhnctI'Hjal_R{UUIWEHENT$ 

«t*  EPRf  ■)  MV  j 


SHEETS  T All  y_Rfc  TuPns  , 


alpha:  sft^trpp, 

F'ETa:  " ME  G J * EM’}". 

nESolPMPN:  " 5E ) 5 type  f -am  i k a gf  n me  n«pppfrj", 

St  ts : 

E*  U TV_Ty»’t  * t,>PPPPfc(i_IMAC,E, 

T P A c F o frv: 

pp  igjnat ing_de  )U i Repeat : 

U S_t>rsrR_PAP  AG*  4Pm_  i_?-S_H-.FU  ir  T)  0H  Al  _«E  OUIREPEE-Ts 

»t*  pPPE  ' M V : 

Sl'Rf*E  T : Rfc  C ?Pf\.ORnF  , 

alpha:  sm_last, 

BET  A I 
"BEGIN 

write  ln(  put  pit.  • ci.  *r*_  times'  ,Clpc«_t IMt ) * 

WRI  TE  lm  (Out  PI1  r , • L AST_p  JLSE  = ' ,L  AST_PULSe  ) I 
WRI  Tt  LN  (PUT  Pi'  T , • s T a r7_  t I Mf  = ' , ST  A»T_T  I »*C  ) t 
LAS  IMPULSE :=ST arT_ti^e ; 

CtSTPTV  r A Mil  I P A T F RtCpRO; 

WRITfcLNtOi.lTPl'T,  ' L 4 3T_p*JLSE=  ' ,L  ast.PI'LSE  ) t 
E.ND)  " , 

inputs: 

DATA;  | AST^P'^St 
UaTa*  ST  APT^T [ME , 

PljTpi'TS  J 

DATA:  L AST.P'JuSt  . 

traced  Ftiftf; 

np  IGI N A T I .■JG.REO'i  I RePEE  t : 

T i S-I'>PSPK_P  APAf,RApH„3_?_3.D_FU  4CTIPMAL.RF  QU I REHE  NTS 
RLEEPRF1-'  hvi 

Signet:  Few^FR  AMt , 

alpha:  sH.l^st. 

R t T a ; "MEG IN  E Nf) » " . 

DESCRIPTION:  "Rpf1«C'S  LflSS  nF  PULSE  WHEN  OVERf'Ut,", 

INPUT  S : 

data:  ti— t2-.mndt)w(»data 
data:  ti-t2_*viIT 

DATA:  Ti~A TnO^W^DaT a 

data:  T3"xMn, 

SETSI 

EA  r I T V_T  YPE  • Lf1ST-FiiLSE  . 
referred  by: 

subnet  : miSSIuG_R'eTURnS, 


ALPHA!  SH.PULSt 
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BfcTAj  MFGIN  END*". 

DESCRIPTION!  ’’RECORDS  vALir,  cp'pttu a1F.P<  RtTuP*t". 

St  T s | 

tf.  r T TV.TVPfc  : »ETUH»*fcr.-P|jLSC  . 

THACFO  Frpmj 

ORIGTNATJ  4G.RE  )lt I PfcF hK T 1 

TLS_UPSPR_PARA(;RaPh_  5_?_5_C_FUNrTlOK  AL_P[  .ClliTNEMt  Ms. 
REFERRED  BY: 

SUBNET:  fxthact_mf  asuwEmFnT, 

ALPHA!  SF  T_SUMMCl>. 

BETA! 

"BF.GI  n 

ACC  ni'JTFD_Fpk  ; s S U M M fc T; ; 

WRITELN  ( Ol 1 T P«J  T , ' C(_orK_T  i*t=  * ,rL*lK_T  I^E  ) ; 

W R I T E L N (OUTPUT,*  ACCOU'JTtn.FdFs  I , AcCOUNTED^FOR)  J 

end;". 

outputs: 

1)  A T A j ACCOU  jTfc.r_F  0 F , 

THACFO  FRO‘1* 

OR  I G I N A T I NG.RE  (31 1 1 RE*'  t M : 

T l S.OPSPK.P  A P A Q R A P H_  3_?_4_A_FU  JC  T I 1 N A L.Pf  Qu  I RE"E  M S 

0»IGINATl‘H;_RFOniRfh  f\t7 

T l S.OPSPP.P  AR  Ar,P  APh.  i_?.S.D_F'HC  T I 0 M A L.Pt &U  I RE  A E N T S « 
REFERRED  by; 

subnet:  su* .returns  . 

alpha:  staptfr, 

artificiality:  artificial, 
beta: 

"HE  G I N CPF  ATE  w A V E F fi  R M_  r A fl  | E RECORD; 

WF  N A j s T 1 t 

•vf3cuapacTE«ISTIcS:si  ,o; 

CREATE  rtAVFF^RM^TARi y pFCORD; 

*F_NAMF  : = T(?  J 

.MF3rUARACTt«ISTTcS:s2.0T 

create  «avef ohv_tahl  v RECORD; 

*/F_N  AME  : sT  3 ; 

HF"cHAkACTERISTIcS:sl,c 

end; 

DESCRIPTION:  "This  ELE*Er'T  INITIALIZES  *AVFF0RH_TA8LE ", 

OUTPUTS  : 

FILM  w A v E F **  R T A h t F , 

TRACED  FPn«: 

ORIGIN AT ING.RC QUIRE LF M : 

TL  S_DPSPP.PARAGPAPH.3_2_l_A.FU  ir  T I 0 N a L _ R I QUI«EKfcKTs, 
referred  bv: 

P.HET?  CC. RESPONSE • 

alpha:  si  'm_e  nf.  rg  v , 
beta: 

"BEGIN 

SEIECT  FIRST  K F C 0 R P FrOh  * a vFF  ORM_t  ABLE 
SUCH  that  ( r f _n a h E. = p L I S^.T^PF); 

IF  Rt  C Of'D.F  O'.lilD  THFn 

ENF  RGy7  = EnF RGY  + ^f.CHaR aC TLRISTir s: 

write ln (Output,  1 clock. ti*f  = ', clop*  ti^e): 

write  LN(  OUT  put,  * PULSF.TYpf.  s ' ,Pii|  s*  **T  yPe  ) J 
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WRITFLMOuTPuT,*  f Nfc«&vs  ' , E nErGY)  j 
END*  ", 

Inputs* 

DATA*  F,„r  RGV 

Da  Taj  PULSF.Type 
FILM  *avep"r  '.ram  t, 

0 U T PI  T S ; 

DATA*  ENERGY, 

traced  fsou: 

flPIGINAT  JNG_Rt  JUIRtt'EM  S 

Tl  S.PPSPR.PARAGFAPh.. 5_?.4.A.F'.NCTIfiNAL.Ft  QL'INEMEMs, 
PEFfcPWf  D~HY  : ” 

Sl’BNfcT*  T4LLy„PtT|jPMS, 

ALPHA  J Sl,M_  IS  AGE  . 

H t T A x 
"BEGIN 

select  first  record  from  *avfform_tarle 
SUCH  THaT  (^.va^KspLlSE.TYPF  ) *” 

RESOURCE  S : sRF  S'FJPCF  5**F  .CHARACTERISTICS; 

W«ITfLN(OUTPi.r,  • CLOCK.  TIFFs'  ,c“oc*  IP'D! 

WRI  TELN  (OUT  Pi'  T , ' f'll  Sf  _T  VPf  = ' #EUL  SF  ~T  YPE  ) ; 

WRI  TELN  (OUTPl'I , * RESOURCES*  ' , RESOifF'CF  S ) / 

END*  " * 

OUTPl  T s : 

Da ra:  RESOURCES, 

TRACED  E R 0 m j 

t&iginat  i NG.RF.au i re>-f  m : 

TLS_DPSPR_FMPAGB  aPm.  5_?.4.A.f UNCTION AL.Rf  GO  I REGENTS 
OR  l”l  N A T l”(;.aE«l.i  I WE^E  N t7 

Tl  S.DPSPR.PARAgRaPh.3  p.S.D.F  UV'C T 1 0 n AL.Rf  GUIREMfc  NTs « 

ref epRed”by : 

Sl’-Jf'E.  T t SU^.RETURNS, 

AIPhaj  T t w m_ e n G A G E M E M , 

BETA*  "HFGIN  N.rtDF  :=STANyPY  EM'*". 

OUTPUTS* 

DATA;  mope, 

RfcFEPRF  D f\Y  : 

R.  JFT*  CC. RESPONSE  • 

ALPHA*  T F R^.T  RACK, 

beta* 

"BEGIN  CREATE  TERMINATOR  rCcorC;  QRop.t  I f*C  » sClolk.T  I ME  » 
CRflP.RE  A SON  •rCr.C0H''4:,r)_TT_tDR0P;  pE  a S ON_e  ;?r_PR  op  j SPR  OF'.  RE  A S 0 N ; 

T1meI0E_DR0P  j=rROP.TI'^7 

C ATA.Rf  CORD_T  YPE  : = TRACK.  T£Rm  IN  A ] I on_Re  PORT  END*  " . 

FORMS* 

MESSAGE*  TRACk.TFrnINaTJOn, 

Input  S : 

DATA:  CLrtCK„T IME 

DATA;  flROp. REASON 
DATA;  PRO  p. TIME, 


DATA} 

DATA; 

DATA; 

OUTPUTS* 

OA  r A j 
DATA: 

data  ♦ 
FILE: 


f)A  I A.REC^R-f’.T  YPE 
WF  A S " 'I.F  "pJJppp 
T 1 ME."F«.nROp 
T i RmT'IA  rnR, 


traced  from; 

OPIGINAT  F-G.PF  QUIW^f  FNT  : 

n S.PPSPR.R ARAGRAPh.  3_?.2.t.FU  JCT  IONAL_«E  QUlRE^ENTs 
iKir,iNATiNG„REfn)i»fcf  f”t: 

Tl  S-pPSPP_PA«AGWAPH„  3_?.3.G.Fl)NCT  J"NaL_RF  GUIREHENTS 

iTRIGINATING.RE'JUI»Ef’  EntT 

TL  5^PPSP«j.PARAG«APh„3_?_S„P»FU'JCT  Ift'JAl_R{  QU I REGENTS, 

REFERPFD"*pY : 

R..-4ET:  CC.«tSP"NSt, 

alpha:  tp  a f K_ initiate, 
beta: 

"BEGIN 

T F E.^tni  TT  at  I or.  :.=Cl^C  k_t  p’E  J 

iMAGF.IPtSHO^IDj 

S T A T[  JSIMTIAL.STATE; 

CpVARlANCFjsTrJTTlAL.CijVARTANCEl 

Track _w ate  :s?o.oi 
r a v t f tpm  : = t i ; 

D AT  A_»F.CMFn„T  yPE  ! s T R AcK_  T M T I A T I 0 N_RE  P "HT  ; 
ENTRY.Tpi£:=CL;iCK..TIHE*” 
wr i teln (Output, • cii'Ck.t ime= • ,ci ncK_TiMt ) t 

WR  I TUN  (OUTPUT,  » T I f E_.^F—  I N I T j A TION^  * , T I me_pi  f _ T ■•(  T T I AT  IOn)  i 
WRI  TELMOljTPUT,  « I M A f}”.  IPs,,ImAGF_I[))> 

RRlTELM(t>UTPUT,  • ST  A T t * 1 # ST  A Tf.  ) ; 

wr i teln (Output,  * ^variances',  covariance)) 

RRlTELMOuTPl'T,'  TRaCk.RATE='  , T W A f K— R A TE  ) ) 

W«ITELN(OUTPl  T,<  v.  A vFF  ('P-'s  I , wA  Vf  F arm  ) ; 

RRI  TEL.N  (OUTPUT  , • (AT  A— pe’C  rtRD.T  Y P£  s ’ , paT  A_PFCORD„T  YPf  ) f 
NRITEL^(0UTPUT,  • t NTRY.T  HEs”, Entry  TP<e7) 

end;", 
create? : 

ENTT  TY„n  ASS:  TMAGE, 

form? : 

MESSAGE:  f p A C k— 1 n i T I a T Ion, 

inputs: 

o a r & * clock. timc 

DATA;  Hp_lP 

data:  I n7  T I a L .C  o V a R I A n C F 

DATA;  I N I T I A L .S  T A T E , 

outputs: 

DATA;  COVARIANCE 
DATA;  p AT A.RFCORD^T YPF 
DATAj  FNTRY^TIHE 
DATA;  IMAGF..IO 
DATA*  STATE 

DATA;  TIME-flF-lNlTt ATJON 
DATA;  TRACK. RATE 
DATA;  «.AVEF,?P,'‘, 

SETs: 

entity. type:  IHAf,{..iN_TRACK, 

TRACFU  From; 

OF  IGF  A TP  G.RFUUIRfFFNT: 

Tl  S.PFSPR.P AR AGRA PH.i_?. 1.A.FUMCT ION aL.REGU I REGENTS 
ORIGJNAT  i”g.REOUIR'eRF~T  : 

TLS.PPSPR_P4M*GRAPh.  3_2_5_A.FIJ’IC  T I ON  A I _Rl  Qu  I RE  HE  NT  s , 

REEephfd”uy : 

R.Nt  T : CC.RESPONSE, 


A l pH  A ; T1„T£>_MF  ASuWt/'F:'  T_t*  TP  act  1 v . 

BE  T a : 

"HK.IN 

v a l u o-  : = twie; 

rat  a »-'_■*{  asmh-f  i -emt  : = t ’_T?_rEr.c  i v l ; 

WRJ  TFLKt  (ftitT^l'T  . • tiff  fc_T  lME  = l.*CK_T  IMl  'I  : 

WR  T TE  LN  ( '“ciTMf  r , ' V4L  Ti'_wE  ri'K^'s  ' , Vdl  t T.IP'J  1 ; 

WHITlLMftJTIMir,  ' p Ai'AR_  ifc.  ASLiPf-fF  r.  T = • ,PADAR_mF  ASliHfc^t  NT  ) J 

t K l>  l " , 

I N P u T S : 

DATA;  T 1 _T  C t T vt 

f t lf-  : 1 1_  r i • 

n u t p i [ s : 

DATA;  PAPAk_"f.  AbURf  Hf>,T 
' A T A ; V A L t 1 ’ _ P E T U P N , 

T P A C F 0 F P ft  A : 

OV  in  l NAT  I J I < I W E A f K T t 

T | S_pPSPF_F  ■••MAf.F  APm_3_?_3_A_F'J  JCTI  ^‘.Al._Pf  (.  L I k E f ENTs 
fH  i”  J .•  AT  I N G__  ^ F'  i j 1 1 1 ^ f A “ T : 

1 1 S_r>PFPn'_ P A W A RP  APh_  3_ ?_^_C_F*  I 'JC  T I AN  Al  _kf  Cl  IMEA  ENTs 
fi  E F E p * F D I v s 

Sihn{  t : ^ xTwact^heashpEmf  nt  , 

alpba:  T3.>,EASMkf m • t_f*tpactia»  . 

beta: 

"be  gin 

V A l 10_Pf  TIIBn:  s«f>L'  (Tfcfl'NC  m_Rf.CE  I VEtO,  n ) > 

P A(  AP^Mf  A SURE  MF  lT;  = T3_hfrf  IvF; 

HR  I T E L M (Put but  , • CL  ACK_T  I «E  = '7u. "C -_T  I"E  ) J 
WHITELNCPUTPI'T,  • T3_Rf  C L I yE  = ' , T 3 wp  cF  I vp. I ; 

*•»  I tx  i\  (Cut  pi  it  , ' v a“u_returns  ' , v ALin_»f.  t.jcn  ) ; 
kRITELMC'uTPl'T,'  Ml'Ap”itASuPEfEAT='*PAl'Aw_MLASijCEPE''-T)> 
t N 0 J " . 

Inputs: 

DATA:  T 4_l.  ECFI'-E 

F I LE  : T 3_('  a T a , 

flUTPUTS: 

DATA:  P Af)APi-‘IEAStlPF',FNT 

DATA;  VALIP_PETUPN. 

TRACED  F P 0 M j 

^PIGIl'iAT  rNr,_PLA)I.IPf  REMS 

H 3_ D P S P W_P  A P A C»P  A P H_  3_?_  3_  A_F  I T I A N A L_R  E CU  I HERE  M S 

'IP  I G I N A T I’G.  >F  Ul  I WEk  E KT  5 

Tl  S_DPi>PR_PAPAGR  APh_3_?_S_C_FM  1C  T IP'  AL_k'E  QUIRE  RENTS 

RE  feppf  o”bv  : 

SUDUET  : l.  A TP  AC  T^'t  ASljPE  mE  NT  , 

ALPHA!  UPOA  TE_PAI)AR_CLi'CK  , 

beta: 

"BE  Gif 

RA  )AP_C|  "CK JsRaPAB  C L PfR  T I ME 
E np ; " . 

Inputs: 

DATA;  P Al'AP_Cl.l'CK  — 1 If-f  , 

1 u T P 1 1 T s : 

DATA;  RAI'Ah_CL',CK  , 

R'Ef  fcERf  D BYI 


.1  p I r,  in  a t i f.  f;_^E  ju  i h i f e m : 

n ;s_r I’fpf-.PA^A.'it.  apH- j_?_ i-a_Fii-,r t i riiJAi._i«f  iU.  i kEMfc Ms. 
RfcFfpkE  > H V j 

w_ \ie  r : cc_[-esp*mse . 

DATA:  ACf  EPT  ANCf  _TH«rsH*iLi: . 

L«CAL  I TV  l L'TAI. . 

TyPtl  REAL. 

use  : r.A  "'a. 

I NCLUt^F  0 in: 

0 A r A j T 1 — T G A TF  _D  A T A 

DATA;  T ,S— G ATE  — U A T 4 , 

DATA;  ACf  Ml'MTE  I , 

INI  TT  At  „VAIUF  : ME  I T he  H 
LPCALIT/j  HLPfUL. 

RANGf  ! "Nfc  I Tme  tv  ,C'T')NTE.ri#SiJkMF  " t 
TYPE  : r Jl  IMF  « AT  Tf*N, 

USE:  dPTH, 

ASSOC  I A Tfp  MThj 

EM  Tl T Y_T  YPp : L^ST_PUl Sf 

fcM  TTTY_TYPE. : HETIJRNFD_P|.;LSE. 

OUTPUT  F P P M : 

AlPw/i.  Sf  T.CliJMri) 

alpha:  sf  i„S'JMUt.l>, 

RE  F E PRF')  by: 

subnet:  su^petupnS 

SlBMfT:  T A I.  L T „P  L T U R M S , 

DATA;  AlPHA_F PRnW, 

LPCAL  ITYj  Lt'CAL, 

type:  peal. 

USE  ; GA  'M  A , 
inclined  in: 

data:  t i — t re  r 1 1 v t 
DATA;  t 3_rf  c f i vt , 

data:  alpha.phasf.tapep, 
local  it  y:  i pc”l. 
type : peal . 
use:  ghm/i, 

INCiUUF  > I m. : 

DATA;  T t-T2_Tw AnSmI T 
data:  t.s_tpansmit. 

DATA;  Avf  HAGF_SIGN4L-pf?'YtR, 

L ec Al  ITY:  i_ r* f m . 

tyfe:  peal, 

USE:  Gaima, 

Inclined  in: 

DATA;  aAKE^ARrAY, 

DATA}  6E  T A— ERRPP , 

LOCAL  ITY;  Lt'E.AL, 

TYPE:  peal, 
use:  ga'Iha, 

I NC LL'OE  u>  in; 

DATA:  T!.T2.PE'EIvE 
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DATA 


t wf.cc  rvt 


OATAj  8ETA_PmaSF_TAPER. 

LOCAL lTv;  u!”a l . 

TYPE  J REaL, 

USt!  GA-ima, 

INCLIi^FO  in: 

DATA:  T \_T2_T«ANSmI T 

DATA;  T 5”tVAN5T'  I T , 

DATA;  C A f OIDaTE.ENERGV, 

LOCAL  I T y : global. 

type:  pem.. 

USE:  BOTH, 

CONTAINED  1 11: 

FILE:  CANDIDATE, 

input  TO; 

At  PHA;  MAX  F— C T f*  ^ A cjf  , 
OUTPUT  F » 0 m ; 

AIPna:  PTCN_C4‘.njpATES, 

DATA;  CAN  JI'TATF_I  AAf.F.^IfY, 
LOCALITY;  GLOBAL. 

type:  TNTtnfp, 

USE:  BOTH, 

CONTAINED  If-  I 

FILE;  CANDIDATE, 

Input  toj 

At  pha : hakF„Copmani , 
OUTPUT  from: 

ALPHA!  ('TC<_CANDIOATCS, 

P E F E A P E D RY  : 

subnet:  f orm— fr  a^e , 


DATA;  CA*  DIDATF_t-.AVEF.oRM, 

LOCAL  I T Y ! Du  0 FJ  A L , 

RANGE  ! "T1 , TP, T3", 

TYPE?  F 'JUMFUAT  ION, 

USE:  both, 

CON  TAP  ED  IN: 

file:  candidate. 

Input  t-’; 

alpha:  m a c F— C om  h a nF , 

OUTPIT  EH flu; 

alpha:  PICK.C ANDIpA TES, 

DATA;  Cl^CK-Ti^e 

t*  a predefined  data  itfm  «h i c h increments  AT  thE 

S A'‘E  PATE  As  FNqAqFmENT  t i * ‘ E , EXCEPT  for  Its 
INTTI  AL.VALUf  WHIM  IS  ARBITRARY*  CLOCK_T1Pe  *Ay 
«E  REGARDED  as  ENGAGEMENT  time,  jt  HAS  NO  CLOCK 
ERROR,  * ) , 

LOCALITY:  global, 

type:  peal, 
units:  seconds, 

USE:  BOTH, 

Input  to: 

alpha:  COMPlE TF^SuMm apy 
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AlPha;  CHI'S  T—  T c-  IN  A T I *N 

alpha:  i •>.  i Ti  ALlZt.SKfn.P 

aipha:  lOh.termimaT  iom 

alpha;  p akE..A|_l  OCaT  I 0^ 
alpha:  hR'hm_tfphimtii*n 

alpha:  Tf.UM_T»ACK 

alpha:  TPAC~_IMTiATf 

A l Pha;  IjPI)  A TE_ S T A 7 f , 

DATA;  COMMA  MD_L'JE:wGY  , 

LOCAL  ITV;”r,LShAL. 

type:  peal. 

USE;  Hath. 

CONTA  l'  EH  T'- : 

FILE:  CO-'PAID, 

output  F p o " ; 

ALPHA;  makF^CYMmAnT , 

DATA;  COEMAND^IL', 

LOCAL  I T Y :"*L  or:  AL  , 

range  : 

"HA  NT  OVEP_IE'At;F  ^POP^TPaCK  , J A- 1 T I A Tt_F  NGAr.tME^T.PODt  , 
TERM  I n A T F*__E  h G A i,E  hf.  hT_piy(  f , c C_f,E 55  A GE _E  R R OR " . 

TYPE:  E Ml  IMER  A T T IV  , 

USE;  HMh, 

MAKES! 

MESSAGE  : ACK'.OHLE  DCEMf'KT 
MESSAGE:  handover 
MESSAGE:  m**:)E_ChanGE 

MESSAGE:  TFRmJnaT JOn, 

INPUT  TO; 

alpha:  v a l I ''i  a t E._he  a [if  r , 

OuTPl  T FR  ">‘1 ; 

A l P n A ! VALl  T A TE— H£ A Df P f 

fi  E F E P P f > HV  : 

R_MfT»  CC_PESPONSE, 

DATA:  COMMA 4D_IMAGE_IP , 

LOCAL  IT  Y : "~GL  o B a”  • 

Type:  Imteglr. 

USE:  HOTh, 

CO^TApET  I'.; 

FILE:  COMMA ‘ID, 

OUTPUT  From; 

AL  PHA  ; MAkE.CommanC , 

data:  commamo_kavefop‘S 

local  ITY|~GLOUAL, 
range : " T 1 , T 2 » T 3 " . 

TYPE:  EMIGRATION, 

USE:  rtOTM, 

CONTAINED  IN; 

FILE;  command, 

OUTPUT  from; 

alpha  : MA*E_C0Mr1ANir  , 

DATA;  COVARIanCF  , 

LOCALITY;  GLOlUL. 


T Y P fc.  I dEal. 

USE : HF  ta, 

ASSOCIATED  WITH; 

EN  T I T V_T  yPt  ! I'iAf’t.U  T»AC*. 

INP'JT  TT: 

A L ° M A ; i.iPfjA  TE_S  T A rL  t 
OUTPUT  F R « V • 

Al  PH/,  j T=?ACK_P.  I T I A T t 
A(.Pma:  ijPOA  TE_ST  AtF  . 

DATA:  CiJP-'f  JT_S1aTF, 

LOCAL ITT;  LOCAL, 

Type:  peal. 
list:  3FTA, 
makes: 

mf  5 s a g e i sTate_ijpoatf  , 

INPUT  TTJ 

4i  pma:  l o *—ELE  v a T j oi^pE tE  wh  I n a t I o n 
al  pma  : « r o u '1_df  TEh^tnaT 

P U T p l • T F R 0 M 5 

alpha:  iipi.iA  TE^ST  a t f . 

DATA;  OAT  A_RFCOKn_TYPF.  , 

LOCALITY;  LOCAL, 

R a n c;  F : 

M R A P A(?— DS  A f;F_fi£POPT  , ST  A T E_  i |P  o A T E_RE  p 0 M T , 

TRACK^TEPt’l'a  T I ON^REPfjF  t7  T P A C K_”n  I T I A T I tj N_P(  POP  T " , 

TYPE  I F UJMEWoT  I "IN, 

USE;  dOTM, 

MAKES  : 

MESSAGE;  P A o a r_  Li  S a C:  F 
MF3SAGF.;  ST4TE_UPi)ATE 
MFSSAGt;  T!?4C<_  I n i T i a t I on 
MF  USAGE  ; TP  AC  K^  TE  RHM1  I ■»  N . 

OuTPt  T F K n m 5 

A | °H  A ; LOMPLE TF.Su^MAPY 

alpha:  f ohm^dpo a te 

A L ° h A ; GHN  S r __ T F S»  I K A T J O.sj 
A I Pm  a ; L 0 Tf  PM  I N A T T ON 
alpha:  RED  I J.TFP*' jf  at  I t'N 

A I Pma ; T f R T R A L K 
& L p H A ; T R 4 C If  I T J A T f t 

DATA;  Cfc|  TAT, 

Dt  SCP  IF  T IOf. ; M>>i  .T'jm  PuLSF  SPACING  F"R  HLAM  SWITCHING, ", 
INITIAL  V AL  1 D ; 3,>E-h, 

LOCAL  ITY;  local  , 

type:  peal, 
use:  doTM. 

INPUT  TO; 

alpha  ; 'AKE^CTMMAtgE  , 


! 


! . 


DATA:  Df»fP_FLAf„ 

LfiC  Al  ITY;  l C C A l.  , 

Type:  d o a l t a n , 

USE:  9PTH, 

OUTPUT  F P n m . 

A| Pma ; F IND^CONFL ICT, 


l 
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RE.F£frSF3  BY  t 

SUBNET;  FO«<„FHAMe, 

DATA:  CPpP„RE ASON. 

LOCALITY;  GLOBAL, 

RANGE  : "GHOST  , REDtlN^  ANT  ,L«w  ,CC„CQMMANR,TO,OROp"  , 

TYPfcl  F 'IIIMF  W A T I CIN  , 

USE  l both, 

CONTAINED  I N t 

FILE:  TEKMTNATPR, 

INPUT  TP; 

ALPHA:  TER’k_T»ACK, 

TRACFD  FROM; 

ORir;iNATlNo-RE'.Jl.JIPEf'FNT  : 

TlS_PPSpr,PARAgWAPh_3,2_?,A,HJNC  TTONAL,WLGUIPEmENTs 
ORIGJNAT  l"r,,RF  OUIPE^FNt" 

T i S,nPSPR,PARAGPAPH,3_?,2,B_FUMrTICJNAL,«t  UUIWEMENTS 

OR  I GI  n AT  I ”f;— 3F.rJU  I Pe  Ff  NT* 

Tl  3_t'PSPR„PAPAr,RAPH.5_2.2.D.FUNcTI0NAL_«{  UUIKfcMENTs 

0RIGInatING.kEqUI»ef Ent: 

TLS_DPSPR.PA«AGPAPH.3_?_2.E.FUNCTIi!JAl._Wt  UDTKEmFNTs, 

data:  orpp_Mmr, 

LOCAL  I T V I r,L  ^ML, 

type:  peal, 

USE:  dOTM, 

CONTAINED  IN: 

FILM  TERMINATOR, 

INPUT  TO: 

alpha:  tf.wn_track, 
data:  elf  vation^ltut, 

INITIAL. VAIMF:  15,'J, 

LOCalItv;  global, 
type:  peal, 

USE:  t30TH, 

INPUT  TO; 

ALPHA  : L1'  x.E  LEV  AT  I flN_DE  TERMINATION, 

DATA:  enf  rgy, 

initial, VALUE:  0,0, 

LOCALITY:  LOCAL., 

type:  peal. 

USE:  r*ta, 
input  nt 

ALPHA:  MAkE„ALL0CaTIOM 

aipha:  sum,e  NfPG  y , 
output  from: 

ALPHA;  make, ALLOCATION 

alpha;  SUM^EhEPGY, 

DATA:  ENGAGEMENT,!  IMF. , 

LOCALITY:  l"CAL. 

type:  peal, 
use:  both, 
makes : 

MESSAGE:  RADAR.USaGE, 

OUT  PL1  T from: 
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&|PMAj  C Tt_Su'' MA«  Y , 

DATA:  E N T R Y,  T I Mf  , 

LOCALITY;  GLOBAL. 

TYPKI  PEAL. 

USE  J H*TH. 

associated  mth* 

E. f>  T I T Y_CL  4S-S  : I ^ Afjf  , 
input  to5 

alpha;  L^w.ELEVATin^nETEPPINATTfH,, 

OUTPl  T FR-m; 

Alpha;  TRACK, IMTjATF, 

TRACED  F«hh; 

3PIGINATING.PEQUIHEPFNT : 

TLSi.>DPSPP<_PAPAGPAPH„  i_?_2->F„FlJ'Mr  T I ONAL_PF  fit,  I PE Mfc  N T s . 

DATA;  F p l \i  D 

(*  A PREDEFINED  DATA  ITEM  *<hICH  IS  SF  T T 0 LITHE15 

TPI'E  .IP  FALSE  AFTER  EACH  SELECT  Or  AN  E'-T  I Ty.CL  ASS 
0 P E,jT  I TY^TyFf  . F P IS  SF  T T (J  TPUE  IF  AN 

instance  satisfying  thf.  slFCUon  criterion  is 
LOCATED,  fiTFERwISE#  FOUND  IS  ASSIGNED  THE 

value  Raise,  * ) t 

I N I T I AL_VALUF  : F ALSF  , 

LOCALITY;  LOCAL, 

TYPE  I HOCLFAN, 

USE;  dOTH, 

WEPtPPE  J B y j 

P^NE  T t CC_RESPO.v,Sf. 

p”')E  T ; RFSPONSE_Tp>_w  adap  , 

DAT  A ; PRAM[_L  ATI  , 

INITIAL, value:  0,01, 

LOCALITY;  GIOHAL, 

type:  peal. 

USE:  HOTH, 

DELAYS: 

EVENT:  SCHEDULE. 

Input  n; 

AIPha:  INITIai_IZE->Skfd,Pi 

data;  Gate, length, 
locality:  local, 
type:  peal. 

USE:  Gahma, 
inclL'DFO  i.j: 

DATA;  T 1,T2, GATE, DAT  A 

DATA;  t3,c;ate,data. 

DATA:  GATt,STAPT_TlME, 

LOCAL  IT Yj  LOCAL, 

type:  peal, 

USE  : GA  hma  , 

INCLl'OFO  IN: 

DATA;  Tl_T2,r,ATt_DATA 
DATA;  Tj"GATF,DAT4, 

DATA:  GHOST, IMAGE, 
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LOCAL  I T y x LOCAL. 
type.:  poitlean, 
use:  opth, 

OUTPUT  fppm; 

ALf’^At  GHnST„uTfcTERPTNATinN. 
tracfo  FROM; 

PR  IGI'.A  T I'jU.PC'JUIWEf  E'KT  » 

TL  S_DPSP‘<->pAPAGKAPH,l_?_iia_H-n)Mr  TIi'GAL.Rf  fJU  I RE  ML  M T S 
OPl”r<ATi”f.;^^F'miWE^  F\T~ 

TL  S_ppspp_FA^AgFAPm<_  3_?_3_C_F  li^C  Tl0UAl_f?f  OuIKEf-’f  NTs. 
REpEPPFu”r>,  y : 

P„'-IFT!  RFSp^‘SE_Tp_BAnApt 

data:  Hn_m, 

LOCALITY!  LrtCAL. 

type:  integer. 

USE;  ^«TH, 

makes  : 

MESSAGE:  Htt’jrivEW 

M F 5 S A G F : STATE.nPfjATE 
MESSAGE:  TF^mimaTiPn 

ME  SSAGF  : r R AC k_  P1 1 T T A T T r v 

MESSAGE:  T»ACk_TF.RMNAT  I ON, 

INPUT  T1| 

alpha:  T TACk_P‘  I T I A TF  , 

nuTPiT  F b p h j 

alpha:  ghpst.ter^ia ati^n 
alpha:  L^.^^jnat  jon 
alpha:  pedun.tf rmjnatiOn 
A L pha:  i IPL  ATE  _s  T A Tf  . 

RECPPne T gy : 

Y A L I r A T T fl  f-  _P  P 1 “)  T : ( 2_  lPAGE_HAJf'PVF.P. 

R E F E F w F 0 t>  Y : 

p_njft;  cC_R'ESppnSe, 

data;  Image. id. 

LCCAl  ITT;  GLOBAL. 

TyPEI  imtegfp, 

USE:  a«rn, 

ASSnriATEo  *irn* 

En T I T Y_C L A S S { IMAuf. , 

INPUT  TP: 

A|Pha:  assignor  a Te 

alpha:  CPtATF;_STAU_FTLF 

ALPHA:  GHPST_  TF  PM  I A T T Pkj 

a | pha:  l'»w.TERM  PUT  1 f»N* 
aipha:  pick„C anpIdates 
Alpha:  HEl)U'J_TE«MlF  att"n 
A|uhaj  uPUATF_STAtF  . 

OUTPUT  FFPhj 

a | pha:  TPAC«_INIT  j a t f , 
p E f f p ;•< { u hy: 

P_^ET:  CC_PESPPNSt 

p”vlE T : PF  sppnSP.T O.pahah 

Subnet:  f x tpact.me asurF mEnt 

SUMNE  T : . F aM£  f 

DATA:  INT  T I »L.C  0 v AM  I anCE • 


j 
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1 

1 

LOC  At  1 T Y;  LOCAL. 

Jyf't  i heal, 

USE  : r)MH. 
m a k f s j 

JF  SS  AGE  I HAJPOVEH, 

Input  Tfij 

4[  p|- A t TP  ACK_INI  T I A TF  , 

DATA:  I in  I TI  ‘L_STATE  . 

LOCAL  I T V J L f'  f A I.  , 

TyPts  PEAl, 

use:  hm.1, 
m a k e s i 

“'FSSArU:  HA-jOpvtP 

MESSAGES  TPaCk^I^iT r AT InM, 

Input  t t j 

AI.Phaj  TPACk.P-  I t i ate  , 

0 A T A s 1ST. 

DESCPIPT tPN!  "INITIAL  Stapt  T I “E  F*P  THE  E«AHE.", 

LOCAL  ITT j LOCAL, 

TYPFI  F fc  * L • 

USE  s d*Tn, 

INF.JT  T'<  J 

AlaHA|  M AkE_ CPI'^AmC  , 

OUTPUT  FSAm. 

a i p m a : INIT  I alTZE_Sked_W 
alpha:  -<  ak  E. _C  Of*y  a mT  , 

DATA:  LAST_all'CaTI  , 

local  it  y:  r.i  n^Ai., 
type:  Ft  At. 

USE:  U"Tm, 

Input  t-*: 

A L p H A : M A K F ^ A L L 0 c A T T fUl  , 

OUTPir  F P pi M J 

alpha:  makf^ali.oc  aHo\, 

DATA;  LASI.^ulSE, 

LOCALITY:  global  * 

Type:  p E a l , 

USE:  soth, 

ASSOT  I A T E r > WITH; 

Ei  tit y— t ype * I^age.In.thack, 

Input  t ' : 

a i pha:  sft.last , 

OUTPUT  Fpr>M; 

alpha:  sf.t.last, 
pe.fef^  o h y : 

p_ift:  sxed^p, 

DATA:  LEI G T o F — R E C fc I V E , 

LOCAL  ITT:  L PC  Al  , 

type:  peal, 

USE  : GA  1WA, 

INCLUDE  > INS 

DATA:  PE  C 1 1 V F — I u E oFmat  I 0N, 
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OAT  A ; LOY.E  Lfc  V AT  IfiN, 

LOCAL  ITT  J l ?C  A|_  . 

TVPEJ  BOOLEAN,. 

USE:  UOTh, 
nuTpi'T  fpow: 

At  Pv-t  A j L'-^LLEV  AT  lON_nETERwINATlON, 

TRACED  FRO «: 

OPIGINATI  iG^WElUIRt^EKT  J 

Tl  3_nPSPP_PA^AGRAPH_3_?_2_C_FU^r  T 1 1"  AL_Rf  GU  IRE^E  F*T  s , 
RfcFtPHF^HV  ; 

Mf-  T » R F S p o N S E. T o.  R A n A R , 

data;  rote. 

LOCAL  ITVj  GLOBAL. 

RANGF  t "EUGAGFD, STANDBY", 

TYPfc:  F 'iU^tf'-AT  TOG, 

use:  both, 

OUTPUT  from: 

alpha:  j ngagf  4EnT_j\i  j t T aTjon 
alpha:  Trw'^e  .'iGAG^r  tnt  . 

RfcFEPRFO  BY! 

P^'JFT:  RAtjAP^SUMMAA  Y 

R^ET:  SKEO^R, 

DAT  A ; NOISF.LF  VFII  . 

local  IT y:  l^cal. 
type:  real. 

USE:  gamma, 
included  in: 

DATA:  T l-TP_,RECOR[5 

DATA:  Ti^RFC'RP. 

data:  priority, 

LOCAL  I T Y : GLOBAL, 

type:  peal, 
use:  both, 

0RCEPS : 

FILE:  CANuinATF, 

CONTAINED  I'.; 

FILE:  (, A » I ) I D A T E , 

OUTPUT  FROM* 

'alpha:  pic*.  Candidate  s. 

TRACED  from: 

DECISION:  TRAC*_pEF  fop*  A ^..ALLOCATION 

OP  I G I N a T I NG.RE  QIJ  I R E F E N T I 

T L S_pP 3P R— (l  A R A (;R  A R h.  3_ p_2_P_PERFOR -i  a nCE^RT GUI  REFECTS  , 

DATA:  PULSE. ID. 

LOCAL  I T Y : G L 0 F>  A L ♦ 

T YpE  : I JTEGt  p, 
use:  both, 

ASSOCIATED  T T m I 

EDTITY_CLASS:  pulse, 

OuTPL'T  from; 

al°ha:  .pic *.C ,mm anI  . 

REFEPPFD  my; 

R.FET:  RE  SpONSF.To.RAr.AR, 
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DATA:  PULSf_TYPr, 

LOCALITY:  Global. 

RANGES  " T 1 , 7 ? , T 3 " , 

TYPE:  r 4 1 1 h E F A T I 0 , 

USE : both. 

associated  - t t h s 

f k’  r i t y_c l a s s : PuLsf . 

Input  r ’ : 

A | P M 4 J SUf'.EMEPGV, 

OUTPUT  ERfi*: 

A | PHA:  PIC^_CYHMAf,,r  , 

R £ f e R R f J hv : 

B_  'FT:  REbP'5"SF_Tfl_RAnAR  , 

DATA:  H ft  r A p_C  l *( K , 

LPCai  itt:  global, 
type:  REal, 

use:  p*th. 

Input  t i : 

aipha:  c,,mPl£  tf_SuFpa»v  , 

output  from; 

A l Rna:  IIPD  A TEJJ  ADaR.CL  TCK  . 

DATA;  Rat AR«CIPC*_T I^E , 

LOCALITY:  l«CAL. 

WESPlUTIO'j;  b,i?S  F-R, 

TYPE:  REAL. 

units:  seconds. 

USE:  both, 

makes  : 

MESSAGE:  R..CLOCK.MESSAGE, 

INPUT  T T ; 

aipma;  upda te_r AOAR.ri oc*. 

TRACED  FRO*: 

OPIGINAT  ING.REtJUIRE^ENT : 

T L S_RADAR-nPS_lFS_PAWAr,RAPH-3-2_9,FUMCTlPfiAL_(RtGUlREMENTs, 
data;  « at ap_me  as'jwt  *f;nt , 

LOCAL  IT  Y;  L^C.AL. 

TYPE:  REAL, 

use:  beta. 

Input  to: 

aipha:  GhPST.DFTErnikaTiPN 

alpha:  iiPMTE.ST  Ajt  , 

OUT  Pi  T FRO*: 

ai  ph a:  t ,_Ta_*E  asuRerf ^.extraction 

A l PH  A : T 3~M£;ASIiREi-lENT_F  xTRACTION, 

data;  Rad ar.typt , 

LOCAL  I T V : t oCAL, 

RANGE  : "T1.Tp.T3", 

T YPE I f NUMERATION, 

USE:  both, 

MAKES  I 

message:  r i.tp.com*  am, 

MESSAGE:.  T 1 — T p„  R F JUPN 
MESSAGE:  T 3_CfiMMAftjC, 

MESSAGE:  T3„RETU»N. 
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n u t p i r f a * • : 

a i_  ai<j : (■  T c " — c Af,i  . 

k t r )(■  ) }.y: 

v *l  I P a T i p rij  4T ; ' ar  c a*>< A jp_'"itr  "T^f  f 1 * T , 

pe.fe.prf>  hv: 

j f t ; pe.  sp  'nse  _t  a^p ar  ap 

“j"  If  T J < I T a 

DATA;  tt  A ^ GE  _K,Ar>t‘_l.F'Nf  ->  A T I rt  f T F rw‘- J'.IlF  , 

L * C A I I T i j L f' T a l . 

TYPfi  I'lTF.r.KP, 

USE;  GA«^a. 

IK‘CLi"-’f  •>  I'-! 

data  : r i-T/,_GATE_r;/-  ta  , 

[)t-  TA  : p A"-  Gf_k'A^K_I  \Ff  ^ ■‘AT  I «‘j. 

use.  2 beta, 
t r r l I • . a r 5 : 

1 A T A • P A \ f,  E — ' A P K ] 1 «p 
TA  TA;  S T G • ' ! A ^ P | i T i ‘f  i , 

I a r l 1 tf  1 11 : 

0 A T A • T 1,^1  P^E  t :<c0 
.1  A T A j T h \'F  C P T.  , 

DATA  2 pAfGF_>,A;>K_TrcHJl  ji.fc  , 

i nr. a i ity:  l'jcai. , 

T Y p e : P f A L . 
u S p : G a * M a , 

INCL'  ^F0  I '• : 

DATA;  T i_G  A TF^r.  4 T A , 

DATA  2 F Af  GF  ARK  _ T T IF  , 

L'TCAlITY-  L a L . 
t yrt  : pEAt  . 

DSL:  gatma, 
if.r.Li  Jr-T  I-: 

0 A T A 2 P AM/.."  A«K_If  F f*p"  A T I . 

CA  T A ; PE.A5A  J_F  Ak_,‘F  Ap  . 

L ft  C.  A l I T i 2 L * r A I . 

KA'-GF  S "GM^ST  # Ft  T.  i|'  .'.A:  T,l  f * , C C »C  ^ M‘’ A M _T'>_n^rt  ••  f 
T YPf.  : F 'tl'MF  P A T I <•  «, 

nst:  «ath, 

M A K t 5 { 

MF?SAGF:  Tk’ACK.TEpF  TKaTJITN, 

A U T P l ' T Fpam. 

A|pha;  G w P S T—  T F Ai  t ” J F-  A T T * N 

AL'JWA2  LAw_TFW*T-AT  JAN 
AIPmas  PFii‘1  J,  TF  K^;  I K A T T *N 
A I =»*-  A J TFW'  _ Traqk  % 

traced  f « r m j 

A R I (T  I \ A T I ’■l G—  P t H'lPfF'FKTt 

TLS^PPSPK.PARAGWAPh.  .^?_£?_A.F!l'‘;r  T I A ' AI._RF  HL'I  WEF  ENTs 

OPIGJNAT  I-G.«C()U1PfTfmT 

Tl  S_DPSPP_P  ar  AQP  ApH_  5_P-P.B_FIi  jf  T I A‘:  AL_Kf  r,c  I KF.f  F F,T  $ 
IH'IGIMAT  i'g.pf.jI'IR^Tfnt” 

T L 5— Dp  5PR— p A R a Gp  A F'h_  J_>?_p_D_F"TC  T 1 *•*  AL_pf  G l I F-F  (■  E N t s 
API  GIN  a T ING.PtOtilR^Tf  gt“ 
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T | S„.DP$pw„P4'*4G‘’*pm_3_?_2_.E..H)  IC1  I"  *L_pf  nuT«E-'F  Ms. 

DATA:  *EASIM_F  ftP_T^AN.jMSSTftr._F  iI|_U*E. 

LftCAi  I t y : ir-CAL, 

P A N C»F  : 

"PPF_F  'PTF:r_T»ANSy  I S S J n»  , 

P E C E I 'J F »I« i) 0 ft  V £ W L * P » 

T P A M S ' 1 7_ ^ I \iPft  3 Vf  PL  A 1 , 

U S OF  FIcTf  \iT_TPAns»'1$sT">_t  I'JE  , 

G AP  AP_C»vn  iCnNS!$TFKr  y , 

TPA  >JS  A I T_ST  ap7_T  I -IF  _F  XCF  EOF  ; . " . 

t v?fc  • { xiiiw”;;  4 1 1 o11, 

I'SF  : ~i  ft  Th  , 
iMCUUtD  IM 

DATA}  T 1 T gll  T ’J  _E  P P ft  I-  — P F F-  ft  P T 
OATaj  T i W T n _E  R P (?  P_p”p  ft  P T , 

DATA*  , 

USE:  r(FTA7 
T N C H 1 0 F 3 j 

) a r a • r r j vp 

OAF  A;  PtCE.IVE_STAM_Tj^ 
l>  A T A ; PFCf  I V/EP.GA  JF  ^SF  Tft  I ‘T,  • 
tncli"?fl)  I-.: 

OAT  A;  T 1 _ T T P A S ^ J T 
OATAj  t i_TP  A’-S’  I T # 

OATAj  Gtctl y F_s T ART_T 
LOCAt  I T 1 s”l  sC  AL  , 

TVPfJ  PEAL. 

USE:  GA'A'A. 

IOCU  OF  t I • : 

OATaj  pl  C E T ^E_I  if  ftp  a T I a'j  , 

DATAj  «LFET  i/F_STftP, 

L ^ c a I I T y S GL  AL  . 

TvPFj  peal. 

USE:  rfPTM. 

Ass^riATFr  '•it-': 

LMttv_typf.:  t'_t^_piL$e 

tMITY^TYPfc:  T J_PUI  Sf  . 

InPjt  Hi 

AL  °-'A  ; sfmf  tt  f , 

ft 1 1 T p i r Fwft'i : 

ALPHA:  K ftp'  _T  1_T? 

A I P h a j F ftp  ^ t 
REFLPWf^ft  '4Y: 

subnet;  m i rir,_Pf_ T"k»  s . 

DATA:  R E.  C E 1 ^FP.r.  4 I‘*_^ET  TI\G, 

LOCaI  I T y * LftCAL. 

type:  weal. 

USE:  Gaama, 

IuClioe)  in: 

OATaj  PECF  T i/F.  _I  \F  ftp  M A T T ftN  , 

DATA:  Sf  C ftCO.Fftl'ND 

(*  A PPFOF.FlNEn  OAT*  ITFM  nwICh  IS  SF  T Tft  lITP£» 
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Tkf  oR  FALof  AFTfR  FAC‘T  SM-F.CT  OK  A F J LP  In 
A q-'TA  0«  GA^k,A.  WP-C0«  J_Fru^'D  is  SLI  TC  T F'OE 
if  a file  »fCf**>n  jatisfyTng  The  SFUCTI0K 
C&ITERU*  Is  l.crATFD,  it  mF  w a i se  > «F  C0<?f.'_F  (*UND 

IS  ASSIGNEE*  The  VaLUF  Eai.SF.  •). 

IMTI  AL.VAUIF:  FALSE, 

LOCALITY:  LOCAL, 

TvrE;  PTHLfah, 

USE:  both. 

o u t p i t 

a i “ha  j selFc  woh-ant , 

RF-FEf-«FD  BY : 

R_nf  t : x-'itjj, 

DATA;  fiEFHkOANT_lMAr,F  , 

LOCAL  ITT:  L'CAL. 

T v Pl  t ^"LFA-:, 

('St:  hoth, 

fT i.l  T p t T ERHM  ; 

A L p h a j PFP'J  J_  3F  T E Hi • T f.  A T I ON  , 

TPacFO  F h « •> : 

OF  IGjmaT  I n&„pEQI  I « t ► F r t • 

TL  S_f'PSP-R_P  A-1  AC.»  APh_  3_?_^_A_F"  <f  TT  oc  AL_«E  '2LJPE''F  a Tg 
OF  I G I NAT  I NG_RF  )(.  I Gp  ► Fu  ; 

T | S-mpspk,.P  aRA^f  a“h_  3_M_F  II  Jr  T T ONAl_Pf  Ql.  I L E. r E . T g , 
pffffnf  t hy; 

j_'jtt;  -rf  sp ’N3E_T^«ArAfc  , 

DATA:  f E S It  "TCE  S , 

local  I t v , l * r a l , 
type : pEai  . 

USE ; BFTa, 
h A * E 5 S 

*F  S S a r, F ! m 4 P A (?_ US  A F. f , 

OijTPiT  TRr“: 

At  Ph  a ; su-'_  1 S a r.f  , 

DATA;  GW. of OFR.IO, 

LOCAL  ITY,  L^CAl . 

TYPE ’ I NTEGEp. 

USE:  both, 

“ A « C S • 

MESSAGE  | T 1 _T2_c0y»‘ ant 
•*F  SS  AGE  : T1_>T2_wf  Tl  RG 

MF  SS  AGE  : T3“co*'«an( 

*F  SS AGE  t T3_KETU«N, 

OijTpiT  From: 

al»ma  : p I c K_C of'i-’ ani  , 
weferrfo  ry: 

W_NFT:  RFSP  0 <SF_T  n_RAHAf,  , 

D * T A : KR.ORJFR.mc, 

IMITI‘1- VALUE!  0. 

LOCAL  I T Y i GLOBAL, 

TYPE:  INTEGER, 

USE:  BOTH, 

Input  TOi 

alpha:  PlCK_ClH*4f*L  , 
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output  from; 

A l FHA  J , 

DAT*!  SlC-NAL.AHPt  ITUOE. 

LOCALITY;  L"CAL. 

TVPfcj  REAL. 

USE  J Gamma, 

INCH  or D in; 

a A T A ; p ANGELA  Rk_|K  F Iiov  A T I r»  rj , 

DAT  A ; S I GN  AL_PR'CCF_SS  I NG— MOPf  , 
locality;  local. 

TYPE;  REAL, 

USE;  Ga^ma, 

INCLUDED  IM 

DATA;  T 1 _T 2_G A T E_D A T a 
DATA;  T3.GA TE^DATa , 

DATA;  STAPT_TI-ie. 

L or.  Al  I T Y ; GLOBAL. 
types  real, 

USE;  HMw, 

ORDERS ; 

PILE:  c 0Mv  A NO , 

CONTAINED  IN; 

PILP;  CO'^aju, 

INPUT  T 1 ; 

At  Ph a ; FInD_CONFL ic T 
At  pha  ; Picnic 1MVA\T 
ALpHA;  3E  T_L  AST, 
ou  Tpt  r From. 

A|  pH  A ; MAnr_C  V‘*<AN(  , 

DATA;  STATF, 

LOCAl  I T Y | GLOBAL, 

tyfe;  real. 

USE ; HF  T A , 

ASSOCIATFU  k'ltH; 

ENTITY_TYDe  : I 17  AGE,  I N_TR  AfK  , 

INPUT  Tl; 

At  Pm  a ; CWL  ATF_STATf  _FTLf 
At  pma  ; ME(’U‘J— Df  TE  p v j k a T i ON , 

OIJTPIT  FPf>“; 

At.  Pha  ; T B A C 1 1 IT  I A T F 

AL  p h a ; tiP|  ATE^STAtE  , 

TRACED  FOIx; 

OPIGINATING.PEQUIR'Ef  f M : 

T l S_l'PSPP_P  AP  AQR  APM,  3_?_3_A_F  UNC  TT*NAI  _Pf  fi;  I R f.  NE  N T 5 « 
D*TA;  STATE _D  A T A , 

l 0 C A l I T Y ; local, 
type:  peal. 

USE;  beta. 

CURTAIN En  IN; 

FILE;  STATE.FILE, 

OuTPIT  from; 

alpha;  makF_alL OC aT I on , 
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0 A T A J STATE.ID. 

LOCAL  I T v * l.rCAl  , 

TYPLI  INTEGER, 

USE;  9 F T A , 

CONTAINED  I N i 

FJLPj  STATF.FILE, 

DATA;  STPP^TIMF. 

LOCALITY;  L PC  AL  , 

typei  peal, 

USE;  30  Th , 

OUTPUT  FRomj 

ALPwa;  remE.hher_StOP, 

REFefpF'T  by: 

SUBNET;  sISSInG.RE^I'FnS, 

DATA;  SUN*ARY_RATE , 

INI TI *1  ..VALUE ; 0,3, 

L*CAl IT Yj  GL^Hiu, 

TYPE:  PEAL, 

USE;  yPTH. 

delays: 

EVENT;  summarize, 

DATA;  TAPGF  T_ J 0 , 

LOCAL  I T Y * GLOBAL. 

type:  integer, 

USE:  d 0 Th  t 
ASSOCIATED  * I T ‘J ; 

ENT  I T Y^CL  ASS  : PULS’-. 

OUTPC  T FROM. 

alpha;  PICX^COH'" anj[  , 

RECORDED  Ry; 

VALIDATI  0'*_P  0 I N T | RArAR_COf-HA  ir_OuTP"T 
REFefRF)ry: 

R_'JETj  RESp  o*j5E_t  «_r  ah &h 
SUBNET;  F.  X TR  AC  T_‘-e  a SI|CE>‘F  NT  , 


DATA;  Tt0E. 

LOCALITY;  LOCAL. 

type;  peal. 

USE;  rjoTH, 

INPUT  TO; 

alpha:  fInO.COnelh  t , 

0 LI  T P 1 1 T FROM: 

alpha;  initialIZE^Skep.p. 
REFERRED  ry; 

R.net:  skEC.R, 

DATA;  ThRESHOl  D_0  « *N..CR  0 S S T nC_  T I ► L • 

locality;  local. 

Typei  peal, 

USE:  Gahma. 

INCLLDFD  in: 

DATA;  ».A'<E-APR4T, 

DATA;  THRtSHOLD_TYPE. 

LOCALITY:  local. 
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TYPE!  PE4l_, 

USE;  Gamma, 

INCLUDES  IN! 

DATA:  T 1 __  r c;  A T t_D  * T A 

DATA;  T 3 — G A T E — P A T A , 

DATA:  THPESH(TLn_"P«.Ct?',S$I  >iG_T  jMf  , 

LOCALITY;  LOCAL. 

TYPE!  PEAL, 

USE:  Gamma, 

IUCILOFO  IN! 

data:  xakl.ap^ay, 

DATA:  T I*  E_3F_PP"'P  , 

LOCAL ITYi'l^CAL. 

TYPE!  PEAL. 

USE:  0HTH, 

MAKES ! 

MESSAGE:  TPaC*_TFrf U aTjPn, 

OUTPUT  FKfi^i 

A L P M A J GHflST.TEPMjN ATTtN 
alpha:  l ^ « T E ^ m i m a T I p ^ 
alpha;  p F L'  U ~i_  T E P m I n a T J ^ F 
alPhai  TEPu_T^AC»<, 

DATA:  TIhE_TF_ir  TTTATIPfJ, 

LOCALITY:  local. 

TYPE!  PEAL. 

USE:  both, 
makes  : 

MESSAGE:  TPACK_ initiation, 

OUTPUT  FROM; 

alpha:  t p aC k_ ir. ITjatf  , 

DATA;  TwaCk_paTE. 

local  ITY,  GL*|«AL. 

TYPE!  PEAL  . 

USE:  dorn, 

ASSOCIATED  x I T h • 

EmTity_type:  I“AGe_ I* _tpack , 

OUTPt  T PPOM. 

alpha:  asstgn_pate 
alpha  I TP ACK.INI T I A TE , 
WEPEPPEO  BY: 

P.NETt  S<lr>«.1’, 

DATA:  t»ansmit.Sta«t , 

LOCAL  I T Y | local  . 

Type:  peal, 
use:  b*th, 

MAKES! 

MESSAGE  : T 1.T<?«COmM  AKP 

MFS5AGL:  T ?_CBMM AnC , 

Input  toi 

alpha:  f *rm_t i_t? 

ALpHA:  FOwu_Ti, 

OUTPL'T  FWOMj 

ALPHA:  PlCK_CNMMA^r , 
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necopded  pv; 

^ A L I D A T I 1-'_P  0 I 4 T ; P AP  aE__C  Ok'M  A Jn^OllTpi  .T_P"'  I f.  T , 

DATA:  T l_T?_GA  TF_rMT  A , 

LOCAl  ITY;  L^CAL. 

T Y p t * E A i_  , 

USE : Bf  TA, 

iNCu-ursi 

Da  TA  | ACCE.P  TANCE_tU»F.  SNhI  l> 

dataj  gate_lE  j r, tm 

DATA;  r,  A Tfc'^ST  A A'  T_T  I MT 

DaTaj  PA“-'Gr_MAPK_r,f  Nf  PA  T Inr._TEO'  IG'UE 
DATA;  SIGfiAL-°fif'CE.SSI  nG  B 0D£ 

DATA;  Thw^SH^l'L1  YT  P , 

C3NTAIUED  Tfl : 

FILE;  TJ_T?«.GATh, 

DATA;  T 1_  T ?«.<?ECL  I VE  , 

LOCAL  ITY;  L^TAL. 

TYPE;  PEal, 

USE ; BOTH, 

INCH Of  S; 

DATA;  AUPHA^E^IOP 
DATA;  T 

DATA;  T)  APftE_Cf  PpPT 

DATA;  ,AKt.AP“AV, 
y A * l S ; 

k‘F  SSAGE  ; T 1 _ T « F T l »N, 

INPUT  T'lj 

A l °H  A J Tt_T,P_MEASl|f.FPrNT_EXTPACTI*,l, 

DATA;  T i_T?-«ECf,«n, 

LOCAL  ITY;  l"CAL. 

Type:  peal, 
use:  beta, 

INCLUDES; 

DATA;  n.USE,  LEVEL 

DATA;  P A C,  E ^ 1 A P H_  I f [ ^p*  a T I 0 N , 

C 0 N T A I P E D 1 1-. ; 

FILE;  Tl.T^iHTA. 

data;  Ti_r?_ transmit, 
type*  peal. 

USE:  beta, 

INCLUDE  S: 

Data;  a L ph  a_ph  a SE_  T ap  e p 

DATA;  PE T A_PH A SL_~APP p 
DATA;  PEC  E~  VE  „.I  NP  fl F m 4 T I 0 N , 

MAKtS J 

MESSAGE:  T t„.T<?_cr,MUAKr , 

OUTPI'T  FRfl.'i ; 

A l PM  A s f.TK-^T  1_T2  , 

DATA;  1 1_T?_'<  I‘K'fl  v_n  A T a , 

L «C  AL  ITY;  GL^HAl. 

TYPE*  PEAL, 

USE  i dfUM. 

CONTAIN ED  IN  I 
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FILE:  T l,T2_MN00*f 

INPUT  T 5 j 

alpha:  SEAL'S!. 


DATA:  Tl.Ta.XHIT, 

L'TCAl  ITf*  r,L"R4L. 

TYPE:  PEAL. 

USE:  both. 

associated  kith: 

ENTITY.Type:  Tl.T^PbLSE. 

INPUT  T"| 

ALPHA:  SET.LfST, 

PUT  PUT  FBftM| 

alpha:  format i_t 2, 

DATA;  T J T 2P  T N— FR  R a u—RE  p APT, 

use:  «pth7 

INCLI  DES: 

DATA;  PEAS'1  ^FPP.TPANSHISSIPN^FAILUKE, 
INCLUDED  in: 

DATA,  Tl_l?_PECElvt , 

DATA:  T3— GATF_ DATA, 

LOCALITY:  LOCAL, 

type:  peal, 

USE:  heta, 
includes: 

DATA:  ACCEPTANCE.THRESHPID 

DATA:  gate_ length 

DATA;  GATeIsTaRT„.tIhe 
DATA:  PANGE_MAPK_Tt  CHNlfillE 

DATA:  SIGT'AL.PPOCESSINC,  made 

data;  THRESH^lD.TyPE , 

CONTAINED  IN: 

FILE:  Tj.GATE, 

DATA:  T3.PECEIVL, 

LOCALITY:  LOCAL. 

TyPE«  peal, 

USE:  BOTH, 

INCLUDES: 

DATA;  ALPMA^ERMOP 
DATA;  rtETA_rpROP 
DATA:  T3«?TN.ERPOP_PEPORT 

DATA:  * AKE.ARRA  y ,” 

makes  : 

MF SS AGE : T3.PETUPN, 
input  to: 

A | PHA!  T3t_MFASUREMFNT_ExTWACTIONt 

DATA;  T3^RFCO«D, 

LOCALITY;  LOCAL, 

type:  Real, 

USE:  BETA. 

INCLUDES: 

DATA:  noise.level 
data:  RangE^hapm.if fo»hation, 
contained  INj 
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FILE*  Ti_l,ATA, 

DATA:  T3.TPANSHIT, 

TYPE:  PEAL. 

USE i 3FTA, 

INCLUDES: 

D A T 4 j ALpHA_PH ASE^T APE p 
0 A T 4 | PE  T A_PW A SE_7 A PF  O 
DATA;  RECElVE-lNFnPMATlr'J, 

hakes  : 

-fssage:  T3.C«HMANF. 

OUTPUT  FRom; 

ai pha;  forh_t3< 

DATA:  T3_"INOOh_DAT4, 

LOCALITY:  GLOHAL. 

TYPE:  PEAL, 

USE:  BETA, 

CONTAIN  ED  IN | 

FILF:  T3„*nDO*. 

INPUT  T3: 

alpha:  set.lost, 

DATA:  Ti_X>'IT, 

LOCAL  I T Y : G L 0 P 4 L, , 

TYPE:  real, 
use:  both, 

ASSOCIATED  PITH: 

ENTITY_TYPE : T3_PuLSF, 

INPUT  T 0 | 

alpha:  set.lost, 

OUTPUT  FRflH: 

alpha:  ro«H^T3, 

DATA:  T3RTN_ERP0R_REP?RT, 

use:  both, 
includes  : 

DATA;  RF  ASO  J_FrR_TR  AMSN ISS I ON_F A ILURF , 
INCLUDID  ini 

data.  T3.RECEIVE, 

DATA:  VAl.  ID.RETLIRN, 

LOCAL  I T Y j local, 

TYPE:  POfl|_EAN, 

USE:  both, 

OUTPUT  from: 

alpha:  T 1_T<?_VE  ASuREHFM_F  XTRAr  Tl  ON 

ALPHA  : T3_M£ASlJREMENT_ExTRACTIflN, 
refeprfd  by: 

M.Nf.Tl  RE3pO'YSE_To.PAnAR, 

data;-  VafE.ar-ray, 
use:  both, 
inch  dfs: 

DATA;  AVF.RAGF.SIGnAL_POwER 

DA  TA  j THRESHOt.D_D0i»N“cR0SSlNG-TINE 

DATA;  THRESHOi>u-lip_CPoSslNG-T  Ime  , 

includfd  in; 
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DATA!  Tl.T^ECtlvF 
DATA}  T 3_WE.CE  I VE  • 

DATA:  waveform, 

LOCAL  I T Y | GLOBAL, 

RANGFS  "Tt,T2,Ti"t 
TYP^t  ENUMERATION, 

USE;  dOTH, 

ASSOCIATED  "ITh; 

ErTITY.TYPE:  IwAGfc„lK_TRACK, 

INPUT  TO; 

ai.pha;  pic  k— c and  I o a tf  s 

(♦INSTANCES  of  EnTiTy_tYPE  I*AGP_lN_T»ACk*) 

A l Pm  A ; UPDATE _ST at!  .” 

OUTPUT  FROM; 

A t Pha;  TRACK^lNITj atf 
alpha:  i.ipda  TE_S  TATE  . 

DATA;  ^.CHARACTERISTICS. 

LOCAL  IT  Y;  GLOBAL. 

TYPE!  REAL. 

USE;  Both. 

CONTAINED  IN; 

FILE:  aAVtMRM.TARlF  , 

RECORDED  BY: 

VALID  AT IPN_POI  4 T j S T A R T I N G_  POINT. 

DATA;  *F„NAME, 

LOCALITY:  GL"BAL, 

RANGE:  " T J »T2»T3". 

type:  enumeration, 
use:  both, 
contained  ini 

FTLE:  WAV£FOR  VT/'6l  E , 

RECORDED  by: 

V A L I D 4 T I O N_P  o I N T : S T A R T I N’G_P 0 I M T . 

DATA;  xmIT_START, 

local  I T Y ; global. 

type:  real, 
use:  both, 

ASSOCIATED  h I T H ; 

Ef ttty.class:  pulse. 

INPUT  TO; 

ALPHA:  PTCX.COHMAfJ  , 

OUT  PUT  FR«h. 

alpha  ; pic<_Cohhan(  . 

DECISION;  RADAR_RESOURCE_CONT»0| _b 1 . 

ALTERNATIVES: 

"1,  THE  ALLOCATOR  SHALL  ASSIGN  TRACK  RATRS  SUCH  THAT  THE 
CUMULATIVE  S 1 1 h op  THE  ENERGY  FOR  EACH  Image  OVER  THE 
ENGAGEMENT  (ThF  "PRODUCT  of  ALLOCATED  PULSE  RATE, 
ENERGY  PEW  PULSE.  AnD  DuRATIOh  OF  ALLOCATION)  SHALL 
NOT  FxcEED  (TBD)  JOULES. 

ThE  fNfRGY  RF UU I R* E 0 BY  T*"F  PApAW  C^MANDS  TRANSMITTED 

across  the  interface  to  the  radar  shall  not  f*ceed 
( t e r> d joules. 
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3,  THE  FnFRGy  REQUIRED  Pv  Thr  kADAR  C^IMAMf'S  ACTft'  Upfif, 

BY  T^E  RADAR  as  OhTtCTF(5  BY  T|,F  CPS  IN  T-£.  RETURN 
MESSAGFS,  Shall  u-M  EXCEED  (TrD)  J«'JLES.", 

CHOICE  I 

"2,  The  FNFRGY  WEDUIREO  PY  JPF  RADAR  C^^A^DS  TRANSMITTED 

across  the  interface  to  thf  radar  shale  not  exceed 

(THOl  JPOl.ES  Shall  BF  T e S T F n F^H  C 0 -J|PL  I A * C 1 AT  The 
INPUT  T y The  “1HTP  IT  INTERFACE;  R AD AR_"U T . " . 

PW^PLEPJ 

"OP SPR  PARAGRAPH  3.2.«(B),  STATrf,F/'T  (’The  OPS  SHALL 
ALLOCATE  R A a P C^hmaNDS  SO  that  Npr  ‘-ORE  than  CTHf)  joules 
ARE  COPHANPED  Pf  P IMAGE,... I)  Allots  F "R  THRFF  POSSIBLE 
INTtRPRF  taT  lo\s  IN  D E T e r h i n j n p the  P"INT  aT  whTch  Tut 
PEP‘FPKvA»'  CF_»F  QUTMFMEfiT  T t.  S T IS  APPLIED.". 

TRACES  T o ; 

PE  IF o r a n C E_ R E j l ! I R f n F n T ; Er  E°Gy_peR_ImAGE 
VALID  ATI  1*1  N_p  AThi  R a D a R_  r O M >•  a n 0_p  I ! T P u t 
validaTto n”p  mnt  ; RAPAR_roMMA..i”_fuirpuT_f  dint  . 

TRACFJ  FROH. 

OP  I GIN  a T I N&.RtQl'  I&E*  E NT  J 

T L S_r  p SP  R_P  A R a ^.R  a Pm_  3_p_'i_B_PERroRMANCE_EEulllRLHLNT  S , 

DECISION;  R A r,  a R— R E S 0 URC  E_C  O'j  T P f i _ B ? , 

ALTERNATIVES J 

"1,  The  Tatar  pO'aLr  constraints  r«ULf  BE  applied  over  thf  Time 
Interval  of  tup  engagement , 

2,  The  R a f a p p^^eR  CONSTRajT TS  Could  be  applied  over  ThF  T^e 
Interval  or  the  r a o a R fra^f, 

3,  The  r APAR  ° o >.  e R constraint  rr'ULD  PF.  A p c l t e p OVER  A EINItF 
time  interval  SPFCTFIE'-)  In  SECONDS,". 

CHOICE; 

"3,  The  f ADAR  poser  cr^  strait  shall  apply  ov  e»  a Time  interval 
OF  ONE  SECOND  and  shall  P-E  TFSTfp  for  COMPLIANCE  TURING  THE 
ENGAGEMENT  FOR  ail  r'AGtR  In  TRACK  kIThIn  each  ft Nf  SEC  OnT  INTERVAL 
FOR  whICF-  R ad  a R commands  aRe  ISSUE0.". 
pro  hi  E P ; 

"DPSPR  PARAGRAPH  3,2.a(S),  sTatf'^/T  ('The  M'S  SHALL  ALLOCATE 
RaDaR  Cof mauds  S o that  not  kore  than , uop  more  Than  (Trd)  kilo- 
watts  FOR  All  I *' A&F  s IN  Track.')  n”FS  NOT  SPECIFY  the  T j n e 

interval  over  whtcn  the  radar  e-ntpcy  must  be  accumulated  to  test 

FOR  COMPLIANCE  with  The:  RaDaR  PoweR  CONSTRA  INI , " , 

TRACES  T o.  j 

pf  RFORnanCE  .REuL  I»Ef  ENT  t RADI  ATE  P„PIVEW 

V AL  TO  A T I rr  _P A T H ; R A n A R_C  0m>  a NP_ OUTPUT 

VALID  ATT  N'  ”p  0 I N T ; RaPa”  C Of’H  A 0 1 1 T PI ! T„F  0 I N T , 

TRACE  0 PROM  I . . i . . j 

PR  I G I N A T I »iG_RFUU  IReHF  N T < w.  1#*  S‘  v J v V. 

T l S f'PSPP  paragraph  J ? u B P r p£  F-f  ^ k f#  RE'Vui  RL  H*S  T S . 

fH  1 ; . V>  * •. 

DECISION;  R adaR.ScheCLeR-RRI  OR  r T j 7a  T i 0 ( .. 

ALTERNATIVES:  ' * 

"1,  SCHEDULE  pULSF_Py_P"LSE,  this  would  SIHPLiPy  the 
r.FTS  BUT  V.  n 1 1 1_  C OBVIATE  OP  T 1“  I 7.  A T I rtf  , 

2.  optin-I7e  oveR  ThE  ENTIRE  FRAHf,  TAWING  Thf  FRAME 
AS  A >* h f i l E GIVES  F-eST  RESULTS  BUT  REQUIRES  WEIGHTING 
Factors  FOR  pi  t SF  E^SFMPLPS. 

3.  F’PI0RITJ7E  PUSES  SUCH  That  any  PULSE  OF  HloR 

PRIORI  TV  beats  all  PULSES  OF  LO-F-R.  THIS  IS 
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SUti  .'FT  I - A l , HIT  C F.  A L I 7 A R L F I N ThE  SPEC  AND  IN 

s^ftvare  1'Fstg>.,  no  a priori  heights  neegfd, ", 


CHCirt.j  "OPT  T 0 fi  3,  PK  I Hr  I T I 7FI1  Pt'LSES". 

prohi  en : 

"IPTlujZAT JON  OF  WApAR  iiSaGE  MEOniP'ES  A FFITt  PAPAr  FRA“e, 
this  implies  a PRinRlTT/ATin.  SD'F.f't  FHR  JMFMIit  OpGERS.", 
TP  Act  S T"; 

W_.NET:  SKtG^R 

x M I T_R , 

TRACED  FRITH} 

r»RIGINAHNC._PF<)UIPEf'FKT» 

T ( S_DPSPR_F  AW  Ar,p  APH_i_?_^-P_FH'‘:r  T T AL_wt  G.l,  I i N T 5 . 
DECISION;  SVNCHkfMnil5-VS_ASYPrHW',Hf,US^TRACK  , 

alter  natives: 


"1.  SYNCHRhn 

ous  tracking 

(OR  Rf  SPfHSlVt  ) 

R E D U I W E S 

The  last  pat 

A R P F T u R n Of 

A J I'  A (»E' 

HE  l SE r TO 

P R 0 D 1 ' C t 

The  r-F  xt  radar 

NRNf P, 

2.  AS  YfiCHR  onous  TraCkInG 

x •» u [ u r or t f.  i r < 

ALL  0 k $ A 

TpaFk  Pl(SF 

T fi  u f S F" 

T Lit  I F r,  i'  H A T 

f Vf  R 

STATE  1v 

J N T "F  r,  aTa 

BASF 

Choice  : 

" A S Y F CHROf.fi  US  TRACKING  IS 

3FLEC.T  F C TO  -^AXI^IZE  ThF 
a l L"wFR  (jP  T !*•  E WF  SF  *'* T. S F 

fm  process i jg  rai'af-  pf  turns, 
this  n o f s 1 o t p r t h i h it  a responsive 

TRACKING,  If  PLEHFnTaT  TPf  .". 

pwghi  Ef-1: 

"TRACK  I fp  t>  CAM  HE  E XPRf  SSf  1 AS 

SYNCHRO!, ", IS  OR  ASYKCF'pfMnUS.". 

T P A c F S TO; 

At  PhA  ! PICNIC  A - 'Ll  UATf.S  . 

T P a c F U F e p H • 

OF  miNAT  IN(,_RE  HJ I W E f F N T : 

Tl  S_  [)  P S P W_P  A R A 5 P A P h_  3_?_3_A_F'Pir  T I ON  Al  ulIPF  F ENTs. 

DECISION;  T Wack_depf  GWNANCE_AU o c a T I " n , 

ChOIGE: 

"t,  ALLOfATir"  *11  L.  Hf  PfRF‘-P'"EP  TO  CONSTRAIN 
JHAG.F  STATES  an!)  PATfS  at  all  7 INF'S. 

2.  P-'LSF.  SCwE,JllL  Kt,  *lu  (>e  CONSTRAINED 

jy  a re  alt  10  u ship  <-etkfen  i h a r,  e 
state  s.  ITS  track  rate  , 

AND  THE  PAoAR  constraints. 

3.  CEGHOSTImg  “’III  Hfc  a f I mC  t T on  or 

w A I , A p ME  AS  IRENE  ► TS  only. 

a,  > IPDATF  S T A rE>  i*  I lL  pf  CONSTRAINED 

BY  TTS  DIFFERENCE 
In  PETa  and  CFp  fPoh  a 
>PEPFfct  F ILTER>, 

b,  FJfcOUNf’A.jT  I 1 agE  FlIninatTof. 

PF  PTflRM  AN'G  E 

/i ILL  Hfc  EXPOSED  IN'  TfWMS  or 
STATES  or.,|  Y,". 
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prf-h  ef  : 

"TRAC*  if  fllCACV  I?  A J "*  J ^ T nj»CTIfl»J 
THf  TPAt“  RaTL#  SUCESSTLl  SG  HE  i)i  >L  IV’* 

ACCJRATfc  PULSE  Cf,MMAErS,  a^O  A C C • ‘P  a TF 
R RECESSING  t*F  ThF  RaE'AR  RlTijRm", 

traces  t >'  • 

A|  PPA  J F TuD.C  n,F  L It  T 
Al  PUA;  G*«t  ST.DETF.RR  IF.  at  I^N 
A I Phas  REI‘l"J_OE  TE  RF  JkaTjPn 
a i pha  : iipoatE.st  a^e 
oa  r a ; pr i rr i t”, 

TRACED  From; 

3R  IRINA  T I jr,_PF./)UI»[;E  E FT  ! 

T l S.PPSPR. PARAGRAPH.  3_  ? _c_A_PF  R f ' p.  R'  * , A r L.  F E 1. 1 1 1 R t F ERJS 
PR  IGIF  Ali”r,_R'E 'll  IRe~Fkt” 

TL  S.DPSPR.f5ARAGWAPH.  T_?.?.‘».PF:rf  pp»  A:gf  [..REl.UlRE  REMS 
ap  IGJFAT  t”r_RE  JlilR'F  F f ”tT 

T l S.IJPSPR.P AW ARKAPn.  T_?.3_a_pepf  fF" Af.r E_*  EluIPE  f E '-TS 

OR  I G 1 \ A T ] ”(,_  R’  F )l  IRLFFNt": 

T [ S_l)PSPR.F'ARAGRArH.3.?.  A.^.PEPF  aR'/r  r t .R  F i,u  I «L  ► [ NTS 
ftRl“jNATI'.r,_PF  )I  I wl * F ~ T” 

T l S.r'PSPP.F'ARAfjR  A Pm.  3_  ?_  3.C.PF  RF  AR"«  Af  f F i | , 1 PL  F t »■  T $ 

JR  l”l  "‘A  T l”r.„Rf  Jl  IR'E'fTt” 

TL  S.PPSPR.PA  R ARP  aPh.  3.?.  3.P.PF  RF  ak* iff  F _l  E uUl  PI  Ff  a t S . 

Et‘TITV_CLASS;  Ai,F  . 

A S S * ( I A TF  s : 

DA  r A j FFiTR  V.TIf-E 
DATA;  I M A G F _ I D , 

C a r p f s f ’ a f : 

E F ■ T I T V.  T V P(  : iR.n’pF  r.^TMAGE 

EF  T I T y~T  YF’L  : JRIAGL.IN  Tp^CR. 

Cpeatet  hy:~ 

A l PHA  : TRACK.IF  r T I A T f # 

trace  o F R a ; 

a C I G I f.  A T r-C'_,,E  T"  I UF  F F NT  s 

T | S.DPSPP.R  Ar  a(,R  iP H.  3_D.  1_a_f  " -r  T T a 1 a|  _Wf  Ul  I R E^  l Mg 
f!P  IGJF.A  T l"t;.RF  JI  1 R L 1 f"t7 

ti  b.r-pspp.r  arac.r aph. 3_?.?.a.f  u*  r t i mi  al_rf  gi  ikfuif  Tg 
ap  IGI\ATII,G.RF.;)I  I R l r f ~ t"7 

Ti  S.F)PSFR.P  AR  AGS  aPh.  $_?_,-'.P<_F"'.r  T I'’1  aL_RF  GcIR’E'Ff  Tg 
np  IGI F at  i”g.R-F  r:t  IRf  *■  r”  t” 

TL  S.DF’SPR.P  arac;R  APH.  3_^_^_C.F  "NT  T I a*  aI_R|  Rl  I k F f'  F F T s 
ARK, IF  AT  ING.RPJI  IRt^F  Nt7 

T | S.DP5PF.P  ARAQRAPh.  i^p.p.D.Fl'ur  T I aNAL.R'L  TR'E^FF  Tg 
a P I G I fi /.  T i”g_ RF.  NU I Re  f F ” tT 

TLS_DPbPR.rARAGPAPh.3_?_?.t.F'liJrTl"F  Al  _R(  Gt  T N F.  f ' E N T 5 
ap  IGI  NAT  r'G.RE'Jl  I RE  r f N T~ 

T L S.DP 5p p.F’  A R a Gt?  a ph.  3.P.  T.A_FU  ir  T I a'-AL^R’F  Gu  TREF  fc  NTs 
aR'IGIF.ATI~G.^F.4lJlP{.  RFmT 

TI  S.PPSPm.P  AP  ARR  APh.  3_?_  J.fl.FUNir  T T Al  _RF  Gt  I RE^fc  N T g 
aR IGI’A T ING.^f  JUI«e”rnt7 

TL S.nPSPR.F1  A P 4 GR a°h—  3_?_}.C_FuurT  I pn AL_pL  GL  IRE’  EF-iTs 

aR'IGIF. at  i”g.RE  jUIr^f  e”t” 

TLS.DPSPIF.I'APARPaPh.  i_?_  3.G.FUN  TTl »L_R'F  fiL  IkE'T  k-Ts 
FR  I GIF.  AT  I \G_RE  'iG  I R' f“  t” 

Tl  S.  f ) P S *’  P . 3 1 F n S t • T I af._  3_c_  3_>  IJ’*C  T I RF,  a L.PE  ( U 1 R F ‘•FEATS, 

RE  FlFPF.0  GY  j 
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T : 

p_if  t : 

5 1 ' '3  M t T J 

sc-Onf  r : 


CC  JJESF-’.Sf 
i?rsfV-S(.TV  A r ■'  .v 

r * t u?  a c t_  ••  e:  >•  s i pf.  r r .t 

W[.C  '1  c r* F . 


TITV_CLASS1  PI  l S f 
a S S " f I A T f S : 

£>  A r 4 ; 

J A f A | 

j a r a j 
DATA* 

cr^rrsF  ’ if  : 

t r r i t v_t  ypf  : 
t'  U t v”t  : 
E»  * j t y"t  yPfc  » 

t'  nrv.Tri't  : 

CkEatlp  RYi 

ai  ; r ir  k 


PHI  SF  _Il' 

P i ! I . S f .T  r F fe 
Ti«r,i  T_ i r 
X ■’  T T_s  T AP  T , 


L ^ S t _ r i ■ i hf 

n “f  r i r ri  si 

r r sf 

T l Pni  rf  . 


C if-' 


r 


ut s tp  ^vfcr,  r>  • 

ALPHA;  pl<  in  P__l_  ‘1ST 
A | PH  A j |,k  -iP”p  'LSI  . 

T P A £ f "I  PPflM; 

) p I r,  1 1 . a t i \g_pe  ji  I wt  f r f.  r : 

T I <?_rM’SPRj_r  APAfjh  APh_  l P_(’_A 


FU'JC  t T r f • a l 


ip  in i \at  i .ig_^F'3|  i p t f f * t : 

T l S^fPSPR^P  A P A r,  P a P n_  A ^_c_P„r  1 1 n T I f*  A l 

'R  I n i * a t I ”h..PF(lli  I p£f  f nt” 
r i s_ t p s p '>_p a p a g w a p >_ '_c.r_F'i'-r  ti  ■v  ai 

f»P  mi  iA  T I NG_HL  31  I PE'  rT  t ; 

Tl.i.OPSPK^P  Arf  AGP  APh_  i_?-2_l‘_Pli'Jr  T T '■’'  l A l 


IP  mi  GAT  r.b_PF  3 1 ' I P L I(u; 

U S-r.PSPW_PAP  AGP  APh_  l 3_P_FIJ  Jr  T I |V-A I 
’pmr.AT  i”b„PF  'JIiipe"f”t7 
n S_hP  SPI<_P  A«A(,P  1IV_  '_?_R_A_FH'-;r  T T '•  Al 

i*r  miNA  t rnn.pE  3i  mv  f~t~ 

TI  S^l'PSP'v^pA  0 A£P  aF>_  l p>_  ,J  p ' * r T !"!■  Al 

•i.  m p.  a r i"*r,_  n:  [Rf~f”t7 
tl  s_r.p$PR_PAPAGP  aPh_  ii  -r  t i cf  al 

1W  mi '.A  T lNG.^t'31' 

TI  3_PP  5PP_P  A P AGP  APh_  J3_F'I  .T  T I "f  A I 

pf  ff-  ppf  mi: 

M IF.  T;  |>P  3h  r.SF  Tn  P A " A P 


Si'HMfc,  T J F X T P AC  T_“£  A S|  hF  mF  nT 

ShUNFT  S ►’  J SS  I'ir,”PE  T I ipF'S  , 


tMI  TY.Tyrt  : itP  f*  pp£  |3—  I ’*  A f?E  # 

associates: 

F T L f ! T F P p T l A T P p . 

cripprSF  5 : 

Ef  T I TY.CL ASS  : I -J  A n T . 

SET  f Y i 

alpha:  SF  t_op.')P  , 

T P A C F 1 F R n v ; 

"pIGI'iat  IGG.PE'  3"  I «E ' tit: 

Tl  S_('PSPW_f’AOAGFAPH_  <_^_?_A_EH'ir  T I ff  Al. 
'll-  mr-iA  t mc-^PEG1 

TL  S_('PSPP_papagKaPh_  3_p_?-H_F  I1  or  TI1*'  aL 
')  P m I NA  T l”f,_PF.  ji.  IHt*IM* 


pf  m i «e i f fts 
Pf  '3l.  T Kt  s F ‘-Ts 
Pf  r,i  TPp.  f i.ts 
Pf  pi.  I P E El  Ts 
Pf  rA  I P F '■  F N T s 
Pf  G L I P' E i" E Ii  T S 
P f '*  l I p f i F I-  T s 
pi  m iP'Enf  nts 
P f Q L I w F I F N T s , 


Pf  I3I.IKE'  ENTs 

Pf  M I K F M f.  NTs 
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T | S.DPSPK.PAPAG&  APh_3_;>_P_C_F  • • J r T I "f- At  .&F  iJUlPFPf  NT$ 
HR I gina  t i ng_pEnu I Rt*  m-  t : 

TLS„l'PSPH„PAS(AG«APH.-i_?.^[).F!J'Jr  T I f»i  Al_<n  &L  I PE'  t T s 

flWlGlNAT  I^G„«fcnUIWEf-  FNT  : 

TL  S_r>PSP'?_>PAPAGRAPH.3_?_?.F_F'J'.,r  T I "I*  A I _F'F  Nc  I Kt  if  NTs 
(,PIGINATIN(,^«E(JIiI«e”fnt" 

U S_rPSPP.P  AR  A(',R  jsPh_  1_?_  3_H_ F 1 j <r  TI  '*‘M.  _Rf  GUiIHE'-E  M s 
PFIGINAT  I T G—  F M i I p?  e ” F ~ tT 

U S.r>PSPR.PARAGRAPH..  3_  ?_  C_F ' I -»c  TIPNAl.Fr  G l ■ I R E h E N T 5 
PR  IG  I ri 4 T lNG-i»f;,jl  I K E I"  f N t j 

TL  S_DPSPG.FARAGRAPh.3_p_S_LL.FUnC  T IPNAl._RE  iJl-  I k'E^t  NTs. 

»E  PE  K RE  !”ry  ; 

Sti^NET:  PEC^Pn.nwpr , 

ENTITY^TYPfc:  IMAGE. I'v.T^ACK  , 

ASS  PC  I A TES  J 


DATA; 

COVARIANCE 

DATA; 

L AST. PULSE 

DATA; 

STATE 

0 A T A ; 

TWA C *.P  ATE 

1.’  A T A ; 

*AVL:  F PRM, 

C P M p r S F s J 

entity 

.CLASS:  I^AqF 

SE'  ( Y S 

A 1 PH A • 

TRACK.  If.  I T I A 

T R A C F V E R n M ; 

PP TGI  NAT  IM,_«EUU  I«Ef  ENT  : 

ft  S_nPSFP_P  ARAQRaPh.  3_  <?_  1 .A.FlNf  T T '"'  Al  _Rf- Ol> T Rf  T NTs 
PP  I G I N A T I N G_  R f 0 U I W £ f F~tT 

TL  S.nPSPK.p”pAC,PAPH.  3_?_3_A_FU  ir  T T '■  Al  _Rf  G U I R E f F NTs 
•TF  l”l  NAT  i”g_  *EUU  IrF  r F~t"s 

T 1 S.DP  SPR.F  A R A Gw  A Pn_  3_  p_  3.G.F UNT  T T nl  At  _«f  '3t  I ^E  ' F NTs 
■•’P  I GIN  AT  I~t;_RMniIN'Ef  EKt” 

TL  S.  p P S P r . S l 1 ^ S E C T I(V'._3_;_3_F  UNCT  Iff  AL_«LM)lREMt  K TS, 
rf ferrr  ; pv  ♦ 

R.-lfT!  c'PN'TSf’L.ME  S^nPrES 
R.Nf  T J PFSr  ’NSE.T^.P APik 
R.nFTj  S*E"_* 

Sr  A f » T ; F f* R '.FR  A^f 
S • 1 3 a . F.  T : R£C  iRO.DRpE  . 


ENTITY. Tyfe:  I pst. PULSE , 

ASSOC  I A TF.  s : 

DATA;  ACCPIJ  JTCD.FnP  . 

Cn>,P|,'SF  Ss 

fcf  TtTY.CLASS:  pulse  , 

SET  PYj 

ALPHA!  SF  T.L'JST  . 

HtF£FWEl>  GY! 

R_  JE  T ! t « N T P " L.  P E.  S E I J P f F S 
SO-L  -i t T J F > TR  AC  T_*t  fl$|,DF  *»E  nT 
$ i H •«  F T • h I SS  I NO.PF  T iicm.S  , 

ENTI  TV.TVFE  s P E T'JPf'Ef,.Pl/LSE  , 

ASSPC I a TF  s • 

data,  a c c p 1 1 1 t e d_  f p f . 

CONprsF si 

E f T T t y.p L ASS l PULS?  . 
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St  T hVj 

MPH4J  SFT_PL'lSE, 

TRACE  0 

SPIGINATING_REr3UIKE>.  fat: 

U S^nPSPK.t'A-JAGPAPH^  %__p_5_>C_Fr,J  >»C  T T ai 
oniGr  ATI^G.^E'T.'IWEtf^T” 
tl  s_npspp_p  ar aqr  sph.  j_?-s_p_F'jNr  t t m al 
hefefrf  i”(?r : 

T S CtNT«RL_«F  s^UBr.FS 

R_JETl  p?  Ai)  AR^SUMfaR  Y 

S'^net  : extract_^e  a si  of  me  nt 

SI  ISN.E  T ; MISSI  iG_p£T|iP>-S. 

EMITY_TypE:  T l_T?_PULSF . 

A S S <?r  I A T F S I 

DATA;  !?FCE  T VF^ST-p 
DATA;  T 1_T  <?_x”l T 
FILE:  H_T2_* 

Cfi^Pf“SF  S: 

L f ti  rv^r.L  ass  : rui  sf  , 

SC  T F‘  v j 

AL°HA:  p ■-»  f? ' T 1_  T /?  . 

R t F E p * F 0 R Y ; 

SUBNET  t EXT»f  CT.’-’E^Sl'Pt  f'F  NT 
SIGNET  : M I SS I fiG_RE  T l'E  • S. 


E^TITV.TYFtJ  TS_d,.'L3F. 

associates: 

DATA;  RECFT  vE_S  TT 
'DAI  a:  TJ_xf-.IT*’ 

FILE;  TJ_.-.I'10<*.,,  y 

r “ w p " s f o : 

entitv_class:  p ij l s f . 

Sc  t r y : 

a l PH  A : E (»Pm_T  i , 

n t f e p w f o by: 

SI  *\ET:  F xTRACT_"E  l Si  eFf'ENT 
SI'B'jeT;  ••I3SlfJG_RETnor>S. 


EVENT : Al  l*catf  , 

F n a rt  i ts : 

R_4ET:  C'nTR"L„fF  Sf'icr.F  s • 

P t F t P R l ) HY; 

w_ JET:  CC_»ESP^NSE 
SlHf  E T ; t.fcC',‘AO_DR^F, 


EVENT;  SCMFDl'LE, 
t n a m e s : 

R_MF.  T:  SNE''_R, 
pelayet  ry: 

DATA;  FWA.«E_RATE, 

TRACES  From; 

epir,iAiATi\G«.Pt:iL,IF'cKFN  t: 

Tl  S_PPSPR_P  AR  AQP  APh_  S_?_?_A_PUMCT  I Al 
ffWlGIA'  A T I~G_RF  JU  IPf  A F N t” 

Tl  3_PPSPR_PARAG"  APh_  J_?_?_H_EU  ITT]  *"  At 
’P  IGINA  T j"(,_WE  jh  IPpf  f ~t” 

Tl  S_PPSPR_P  ARAf-.E  APm_  J_P_f>_r_F  U If  TtrtfAl 


RE  Ql  JKEf.f  NTs 
RE  QUTPFI  f NTS, 


PJ  CL  IRENE NT$ 
Rf  NL T RE f t NTs 
Rf  fJl  I RE*'E  NTs 
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np  ir, i-  mi  u;;_ar  at  iwf.f  f.m  : 

T L S_[>PSPW_PARAgp  APh_  3_?_2_l>_Fii\'r  T I A L _ ^ f G U I k E n F t Ts 

'1PIGINAT  l"c._^M')IPf f F~t7 

n s„npspp-p4^AGpAf,H.3_?-?_E_r  i ;r  t i*\Ai_&f  go  iff*'  f nts 
?p  iHimat  i'g^^eoi.'IRe1'  f~t7 

T I S_r)PSPk_F  At?  AQh  APh_  •>_?_  J— 1)— F'jNC  T I*r-  A|._«P  Ql  IkEf  t NTs  , 

«t  F EFPF  i.'”nv  : 

R_JET:  CC_t''£3Pi‘-.SE 

P_MET:  X"7t«s'  . 

EVt^  T : SI  * A R I 7 E , 

ENA m ES: 

R_  JE  T J M A I AR_SI  /*'*■  A»-  V , 

DELAVtn  HYj 

0 A T A : $ |Mm  Ak  Y_P  A Tp  , 

T k A C E 0 F k t}  M J 

a I'  fr,  IN  AT  ir.r,_PE  Jl  I ^ e;  f-  FNT  : 

ri  S_DPSPR_P  a R A(;k  aPh_  W_S_P_FUHr  T T *•’.  A I _kf  Ql.  J K E i f NTs  , 
REFEkkf  T^HYS 

k_JET:  CC_PESPnt.SE 

R_YFT:  k a”  a R_  Sl<  n n a K y, 

event:  xph. 

ntSCk  IPTl  *•'  : "TUP'S  t>N  w_M  T Xf  I T_k  r-P  ThF  Cl'MfNT  fF-AyE.", 

ft.  a m es  : 

k_  nIF  t : x *’  I T , 

T k A c F L)  Fcrvi: 

np  I GIN  AT  I OL  I«Lt  F t.T  : 

ri  s_nPSPr'_P4RAr,PAPH_  s_^_t-’_A_Fiiur  i t ai  _«»  u iRff  nts 
Pf  i“inati”g_pE  j!  I k,  f 7 f T tT 

T l S_PPSPi'_F  A k A G P A P n_  3_?_,?_F_FlNr  T I"’  AI  ,_P|  3LTM  M kTj 
np  I G ] N t T I~G_PE  !)*.  1 we"f~  t7 

Tl  S_T!PSPW_P  A P A gR  A t'n_  l-T  T I AL_P|  U.  IkF  ' [ f Ts 

nplGJNATl  \IS_PE  ij1;  I R f ”f  N t7 

Tl  S_|  PSPk_k  APA(;PaPh_  u Jf  T I fl  >AL_P{  NLIPF.1  ENTs 

'T  P I G T N A T I ' . G_  P F 1 1 N I R E f f ” T t 

Tl  S_OF'SPk_PAkAGP  AI'H„  i_?_<?_F_Fll'<r  T I fl  '■  Al  _PF  G 0 I k F.  N F N T 5 

I !•  I G I ■>.  A T I Jl  I » E ' T ~ t7 

Tl  S_['PSPk_k  A k A qp  a p H_  3_  ?_  j_i?_F  U'lCT  T n\4L_Pf  QL  I kEt  f NTs, 

R t F C k k F ) PY: 

N'_  JF  T J SkFP_" 

W_JF  T j X'  I T_R  , 

FILE;  C A » 0 I 0 A T F , 
cns  1 a it  3: 

DATA:  CAM.  I'A  Tf_Er*F  r?r,Y 

gata;  r a uiT  t a te_i i tc;r _H' 

l'  A T A J C A J,'  I n A Tf  _*  A V f F "RI- 
GA TA;  PRlfkTTY,” 
nwcEPEr  «y: 

C*  a t a : r h 1 r p 1 t y , 
kEFEkkf  -’  r y : 
tk_  '•  t T ; 

FILE:  CaFt'AMR, 

CPNTA I N S: 

DATA*  r i -it.  a 0_f  vf  Rf  y 
g a t a : r. r't.A  jt_i HAGf._Tn 
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r tV  • A :Q__t%  a v h f*R" 
ST  4f'  T_r7f,E  . 


Data*. 

04  r 4 • 

Input  tm. 

aiPma;  PIC^.COf'MAsn 

ai°*'A;  sf.l^c  t^cmmand. 

flROfcttr  Fy; 

0 4 T A • r,  TAP  T_T  JN£  , 

F I L t : STATF— filf. 

Lf’CAl  ITV:  L^CAL. 

Ci'M*  I*  St 

0 A T A • ST4fC_0ATA 
PATa*  STA  rF”lO. 

Input  i i j 

A l P m a j A 3 3 I G 14  — F A T p 

A(PHAJ  ' « r f _ ALLf!  CaTI^N  , 

«u  T PI  T fw r*r<  J 

A I ° H 4 ; CWT  A TF__S  T 4 if  _f  T L F , 

F ILL  S 

C (J  NT  A I F 3 ! 

:)A  TA  : r'|<fH'_WF  4SPN 
JA  r A . r>lv‘H,_T  T 'F  . 

AoS-’f  1 4 If  r;  - I T-’i 

fc»  TTTV^TvPf  : f'it  rif'pr  Tk'A(if  . 

f (J  T P l T F;,»mj 

A|Oha;  G'i^ST_Tff<MjFATlFN 
a i Pm  a : l TF.  rp  l N'aT  I nr. 
a i a : »?r i i TE  pf* 1 a t t ri> 

At  P^A  : T*-  »•’  _TP  .*•(.  * . 

F I L F : T 1_  f P 4 T 4 , 

LflCAl  IT/.  LrT4l.  , 

C P \ T 4 I F s : 

l' A T A : T 1 _ T • 

FA'/f  F : 

'•F  3S  AC, l : r TLPF  , 

T N F I ) T T T ; 

a l '’Ml!  1 'F.  ASyPr^f  KT.E^T^Ar  T]  lAf'  , 

f IlF  : i i_t?_gatf  , 

L^CAl  IT/:  1/t.al, 

C * \ T 4 I f S ; 

GAT  A;  T 1 _T e_G A TF_UAT A , 

M A K £ s : 

P F S S A G F • T I.T^r.^M-  ANP, 

-uj  t pt  r fr pn  : 

A | PHA  ! F ’ IV  T 1 __  T ^ . 

FILE:  IIJ?^IMa,( 

c (am a If  s : 

MATA:  Tl_T?_“.INm*_PATA, 

associated  ;% i r h ; 

fc.f  TITV_TYPF  : M_T2-P(Jt  SF  . 

OUTPUT  F P r M j 

At  PHA  J F t„T?, 

FlLf  S T3.0ATA, 
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LOCAL  I T v * LOCAL. 

COM#  US  i 

o * r a : t i^KL'c 

makes: 

mCSSAGEi  T S_*E.  Ti.i^  , 

INPUT  T a j 

AI-PHAi  T 3_f'E  ASIiWn'FNT_LxTHACTI«N, 

FIlF:  Ti^GATF. 

L^CAl  ITT:  LOCAL, 

CONTAINS: 

o a r a • Ti„t>A  tf.J'a  t a . 
makes: 

message*.  T^C^MMAfjr, 

a u t p i r fpkm. 

alpha:  formats, 

film  T 3„  o J N P o * , 

CONTA  If  S: 

DATA:  T5_'|]ND^_')4T1( 

ass  or  i a rp  f;  > r t": 

El  n TV_TYFr:  T3_PllL  SF  , 
outfit  F p (i i « : 

a i pha ; pop t 5, 

FILE:  KAVEF  30f_TAi*Lfc  . 

conta  i»  s ; 

DATA;  *F_CHA -JAC  TF  i?IST  TC5 

n a r a : ^"la^e. 

Input  r»: 

A | Pha;  P T C * _C  A N ['  I p a T P S 

a i jma  : s*i- _E"t»C-v. 

0 u T P l T F u 0 m : 

alpha;  s t a ° r f.  h , 

R£C  OF  Of  i)  '*  y : 

V ALTr  AT  I IIN^PO  r\T  : ST  apt  r G_PO  I NT  . 

INPU1.INTF  HF  ACE  : CC_I'J. 

connects  t': 

SI'^SySTRa;  SSC2. 

E N i ctl  ES  : 

^_'>ET:  CC.PESPONSt  , 

PASSE S ! 

MESSAGE  I m a 1 0 fl  V E R 
MESSAGE:  «i['L_CH4Nf  p 

MFSSAGE:  TEHMINATirv, 

TRACFO  from: 

OF  I G I N A T I Nf,_RE  l)l>I«Ef  ENT: 

Tl  S-nPSPK_p";<AG«APH_3_?_  I.A^F'IMr  TI  Of  Al.__WEi3l  UEI'E  NTs 
OF [Gif  A T UCI«Ef  F N T : 

T i S.nPSPK.SiJ^SECTI  Of  _*_<?_  1_F  UNC  T I op,  Al  _HE  r,U  1 RE  ME  N TS  , 
reflfwf::  hy: 

K.'JETt  cr_PESDONSE, 

INPUT.INTtRFACE:  RAn*P.CLOCK.TF . 

CONNECTS  TO: 

S 1 1 9 S Y S T E M j SSRAOAp, 

FN*bL  ES5 
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r_jft:  pAi'A^rr*  tno. 
pass?  s: 

Mf  SSAGt  j P.CL  iCf_mE  SSAGt  , 

referred  r v i 

R..NET:  MAl)AW_TlPlM(  . 

UPUT.IMFWF  ATEl  KADA^.IU, 

ntscp iptian: 

"ThF.  PAOpi  l NT E PRATE  PROVIDES  THE  *“'F  CMA*~-1  T F fr  P Li  G H 
HHTCH  the  ops  PeCFTvFS  Radar  subsystem  tpruhSS  I N 
PESP^tlSt  Tfl  WaHaF  f p f m a n p s I S SEE:  f Py  THf  DP  6 THROUGH 
The  RAHO'IT  I n TF  rF  a t f • RAC  AW  SUMSYSTtM  RETURN  MESSAGES 
SHALL  C M M P L Y * T j C R F I J 1 R K M F ' I T S S P t C I F I H f IN  ThE  TlS 
RAOAP_rpS  InTepracf  SPECIFICATION,  pAhAt;RAPM-3_2-6,"f 
ECJTERFr.bY : "H,  A,.-tELT?N,  wAy,  3,197b,", 

CONNECTS  TR; 

SI'RSYSTEMj  sSRADAf, 

ENAhl  ESI 

R _ n E T t t?  E S p ^ r*  S F _ T p a p A p , 

IMPI.F  -F'JTSl 

vr rsi nr.  j Am  np,  al_f  it-l  icattmnj'ate('_augl  st_19/e, 
paSSFS: 

MESSAGE j T1.12.RCTIRC 
MESSAGE:  T3_RETURFi, 

T R A C F 0 FROM} 

A p I r,  I n # T I ' ; r,  _ J E ■ H - 1 w e f ' F k t : 

T|  S_|,PSPR_SF  C T r-C  T T ?CiAL  — RE^M  1 RF  < F.f  TS 

«R  I G j N A T l”r,^RECJHIWf  f p”  T : 

U S_f)PSF,R— SUOSEC  T T oC_  W_  *_FUNC  T T on  Al_REU:  I RE  "L  K T S , 

RE F F R RE  D**R  y ; 

R_hE  T i RESriNiSF_Tn_F)ArAR. 

message:  acknowledge ''t  * t , 

FORMED  ciY  ; 

alpha:  acknowledge, 
mace  my: 

0 A T A : r,  r» r ma  jO^I  D , 

passfd  r h r o i.i g h j 

T ! 1 T P 1 1 T— T f- T F c F A C F ; c c_  ^ L T . 

message:  handover, 

mace  my; 

dataj  c 9 ■•<  m a ■ i it  ^ i i' 

data:  hp^jd 

DATA:  In"t I AL^CIVaR T AMfE 

DATAj  IWITI ALLSTATE . 

passe o through: 

ifpi'T. Interfaces  cl.ih. 
traced  from; 

origihat  Ing_«E  ji'l«Ef  EM  i 

Tl  S_PPSPR_F'4RAGR  APh_  S_?_ l_A_FHNr T I 0 N A I _WF  U U I * E * F R T S 
pp  I G I m a T I *-g„RE  Ji'IREr  ENT : 

TLS^DPSCR^PA^AGR  aPh..  3_?_  1_P_FU  J T T I m n a l _ R F Cl  I REf't  F Ts, 

MESSAGE  I mm OF.CHANGE , 

MACE  My« 

data*  co"*‘a  jn_in, 

passed  Through; 
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lNf»UT_P  TFPFACtl  CC_!t'. 

TRACED  FPfl'ij 

t}R  IGINAT  ING.MF  .JUl(JEr’'FNT  ! 

FLS_Df,SPW_PAR4GRAPH„^_?_  l.H.Ftl'ir  T J (,VAL_Rf  f.U  IRE''  t'.Ts. 

MESSAGE!  H.CLi*CK„<-'F3SAGFt 

rape  hv  : 

DATA;  R Ar.-AR_CL'1CK_T  iKf  . 

PASSED  T HR fJUG h ; 

If  PUT_lNTERPACE l RAnic_cl ACk^In, 

MESSAGE:  RAD  ARAL'S  age  . 

formed  ^V{ 

alphas  c.  ample  Tt.Sljf  ‘'ARY. 

MADE  d V : 

DATA;  DAT A^RECARD^T YFE 
data;  F.nT,AGE*E'MT_7iwF 
DATA;  RESOURCES. 

passfd  through s 

fit1  tfuit_ in t erf acf  ; c a t a_pE ci"ro . 
travel!  From” 

"PIGINATI  N'G— RE  ijli  I Re^E  nt  ; 

T L S— DRSPR_f’  AR  AqR  a I’m.  3_  ?_3„D»F|Hr  T I Of  A I _R|  Clj  I R Er  E NT S . 

MESSAGE:  S 1 A t i _UP(>  A T E , 

FORME  > H V ; 

alpha:  f orh_upd ate , 
mace  dvr 

DATA;  CURrF.N  TESTATE 
DAE  A;  DA Ti_RECPRP_T YPF 
DATA; 

passed  through” 

'3i‘ TP(.n_  interface  ; r ata^rEC^wo. 
traced  f r 0 m” 

Pp  IGINAT  I Nf,_REntlIR’Er  E ^ T : 

Tl  S_yPSPR_P  ARAGP  aPh*  i_?_E>_C„F UHr  T T « n A l _Rf  Qt  I RE  'VE  N T S . 


MESSAGE:  r f R *'■  I n a t i o f' , 

m a c e hy: 

Data*  CfiMM AMD  10 

d a r a j H '_it. . 

passed  through: 

p.PtJT_lNTFWFACE:  Ct.TN. 

TRACED  FR-, 

TP  IGI  -i  A T IN&-REi)UIPEf/E  ► T : 

TL  S_PPSPP_P'RAgRAPh„  ?_?_  1-w_FI.In'CT  I nf-AL_RE  Gl  I RE  ME  NTs 
"RIGINAT  i”g.RE  H'lR'F^  F” t” 

(L  S_DPSPR_r  ARAGR  ArH_  *_?_?_E„FN  ir  Tl  Al  GUI REMEMs, 

MESSAGE:  T P AC  k_  I f,  I T I A 1 1 ON  . 

FORCED  dv: 

ALPma;  TRACK.INITi  ATE  . 

«ACE  dY: 

CATAj  PA  TA.RF.CTHD^T  YPf 
DATA;  H(1_in 

DATA:  INITIAL — S T a Tl 

DATA:  T r-*E-,FIl  N I T 1 AT  T Or  , 

PASSFD  Through: 
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fJliTPi'T_IMtHP  ACF  : r ATA^pECPPO, 
twacto  Frau; 

TP  I G 1 Ai  A T I -i  G_  ^ fc  C3  • I w fc  F M ! 

U S_OPSPR.f1A«A(jPAPH_i_?..S„A-MI,-!rT  If^At  _Pf  (il  T$, 

ME  SS  AGE  : TR  ack_te  pm  i pa  T J nr, , 

FORMED  BY;” 

ALpM4j  Gh(*5T_TE«mIk  AT  Tf*r 
ALPHA:  l TE  ph  I '"m  A II  n f 

A l ° M A : R F n iJ T E R M 1 1 A T T ^ ' 

ALPHAJ  TF RH^TpACK . 

"Aft.  jv: 

r>  A r ft  J DA  T A — T VFF 
DATA}  H 0 _ I D 
OATA;  RfcASft M_F*W..pR "P 
0 A r A j T I«L_  TFj;pnp. 

PASSFO  Through: 

31  ■ TF*'  * T_  T N T t PFACF  : ( AT  A_(.'EC"FO, 

T W A C F 0 FPCm. 

ip  I r.  i hat  ing_RF  qIjIPe'  F kt  : 

Tl  3_DPSPP_F  APAGF  APh.  3-?_b_B„.F'lMrT  I np  AL_Pf  «U  I P F < F N T S . 

MESSAGE:  T1.T2.CWANJ, 

FuUTEr  to: 

s y j n m y 'v' : t ' r<?cr’P . 

FORrlf  ')  r»  V : 

ALPHA:  F p 1 _T  t — T <?  a 

M A C L i't  l 

DATA;  p A I'  a P _ T y r E 
0 A T A • P'P'^nPTF  R_[0 
iUTaj  TP'AnS  M tIs  T A(  t 

data;  t i_t?„tpa\si*i  t 

F ILF  : T )_T?.r;ATfc, 
p aSSF  o Through* 

.H 1 T P i I 1 ;j  T £ p F A c F ; f a r.  a R _ ou  T , 
tpacf;  fp9mT 

f t g i * . a t r g„«e  fpt  : 

tl  s^dpspp.papagpaph^  $_?_3_t_Fuvr  t i al_Ri «l  I pf'F  t. t s 
IPlr.lNATI'-lG.PEOIHHEF  F M : 

Tl  3_0pSPP_S,,HSECTIpf  _3_r_3_F  UNCT  IflHAL.PE  GtJIPfc  "t  MS  , 

MF.  SSAGf  : T I.T^Fr  T'![f  , 
tOLATEr.  T * J 

SY  J C* r ; Y '•  J T t T2PTW  , 
hage  by: 

iTATAj  PAGaP^IvF’E 

jaTaj  pp_r>P'”pp_jn 

DATA;  Ti”t?_PECEIvF 
F ILF  j Tt_T?J’ATA# 

passfg  Through t 

If °"T-I \TFPF ACE:  RAfAD.lM, 

TRACFD  FPVJ 

OP  I G I Ki  A t I P G—  R F ■ H1 1 P F f FMI 

TL  S_r)PSPH_PAPAGPAPrC3_P„3„F«.Fl|fJrTI  Of  A I _Rf  GU  I PF  1 F F-  T s 
•Ip  IGINATl”o.^F.rJl'IPf  f f”tT 

Tl  S-OPSPW-S"PSEC  1 InP.3  d 3_P  (INC  T I al— Rfc’f.U  I PE  ML  F TS, 


mfssage:  Tj^rnMHAf.o, 
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FQIATEP  Tp: 

SVX^NVMl  Tic^i', 
f 0 R M F o ; 

At  3H  A ; f 3 t 

RAPE  ctvs 

P A T A | R'  a 0 A R — T y P t 
DATaj  RV_3R”fc  r_  J P 
pa  M j Trlr  3 M I.STAR  T 

OaTAj  Ti-Tf.AhS‘,IT 
EIUFj  T J^G  \ T r , 

P A S St  0 Through j 

ni'TPuT->!».TE.^F4CF:  R apaR_^UT  t 
T R A £ f f)  FRpm; 

■JR  IG  I S a T r-G«.Jt  R 1»E  N F M s 

U S«pPSPK_PARAGwAPH-.t_(>j_5_F-FU  Hf  Tin  AL_R[  rJ  U I F*  F r E F- ^ s 
fir  ir,IVATl”G,RE.jUIPt.”r \t7 

Tl  3_PPSPh_S,|qSPr  T I PI  IINCTIIINAI R E C.  U 1 W E « L t TS, 

MF  SS AGE  I F3_beturn, 

EGUATEP  TV. 

S V j V.Y'''  : T V4  T‘!  , 

v a r e rt  v : 

DATA.  BAPAB_TyPt 
DATA;  rr_*iROER_IP 
OATA;  T3~KF.CE  I vE 
E T L F ; Ti_D-\TA. 

P A 3 3 F 0 THRfilir.h! 

I N P 1 1 T — I N T F R F A C E : R AP  A P„  J * . 

trace  o frci”: 

flRir,iNATiNG«.RE.Ji|IPEf'FA  T ; 

U S^prSPR^TA  ?AGR  APm_  3_p_  3_F_F  U:lr  T T ^'.AL_Rt.f3UIFtFE  NTs 
(1R  I G I HA  T i”g,RF  3 1 i I K f-  f F~t7 

T|  S^PPSPR^SUPSEC  Tin  _W_  3_R)NC  T T flrjAL_RF  UJlRE^t  R TS  , 

0 P I G I N A T I a G_RF  QUI  R[;  "L  'T  : 

TL  S_uPSPR_  P A p a gE  apm_  3_P_ 1_  a_f  t \x  T I V a | _ReRU  T RE  MF  >\TS . 

PL  SCRIP  Mm: 

"ACTIOS!  ACCEPT  cE  p t S S A G F > I ‘J  T T I a T t TRAC*  f-N  U'AqE, 
SF  'IP  W A C A R f-  R I ) E R 

INFPR'  * \ n IN  ; C<?  F f S S A f,  F XINITIATF  Track  CfiMhAFiC«# 
RA'jT  f'VPR  IMAGF,  RAPAR  PRrfcR", 

II-PLF  m E ‘ 1 t s S 

-/FRSIP*  : TLS.JPSPR, 

TRACES  T-*. 

A I.  PH  A t E ''GAGE  qE  fJT_  J ►'  I t T A T I AN 

A l PHAt  oTARTF.R 

a i pha  : traCK^IMTi  ATt 

a i pha  ; v al  Ida  tf_H(.  apf  u 

tf  T I T>_CL  ASS  ; T - a c,F 

fci  TTTY^TYPt:  TP AGf_ TN^Track 

r put.I’j  rp RR  ace  : cc.i" 

MF  SS AGF  : hAi'.in^VEP 
fll,TP|iT_lGTEPFACF  : CC-‘*l.T 

PL  TPUT^IA  T£RF  ACT  j R A ~ A R fijT 

R.'JETj  CC.RESPHNSF, 

UflCUREi-TFP  Hyj 

Sf.lRCE  5 TLS_OPSPR,>  1_TR  ACK_LT.iP_F  xPf  PI  "ENT  , 
INCnRPfRATpn  inj 
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3 P I G I N A T I *: &—  R F .3 1, 1 E f K T : 

T l 5_nf’bPr^-b"nSt.C  T I "f  _ J_2_1-f'U^CT  I o\ aL_pfi  "I«f.-t  MS. 
OP  1 1;  I N A T P G_RF  QUI  «E.Mt  NT  s 

Tl  S.CPSPw^PAS  Af,R  APh_3_2_1_a_pF  PF«Pf'ANCt-f^rOliI^t'‘fc>-lS. 

I ('  P L F *F  'JTS  1 

v'F^Sirif-t  TLS«0PSPW. 

dpcui-  iK  ff  r f; v • 

S^  IPCf  l TU  S_OP.cpp_  ^ 1__tR  aCK_L"  ’’P.F  XF'tPlMf  NT  , 
pp  If; I naT  iNG.^EQi'lPfc  ,4L‘;T  : 

TLS„C'PSPR_PAR  AGP A PM_  ^_e>_  1_ «_F  1 *'CT  I P^Al  _REPljT  ‘-f-  nFnTs  . 
INPlT-FMTSs 

VF'TSIPN:  TI  s«i)PSPp. 

TKACFS  T<1j 

"EoSAGF  j h A N 0 ? V E P 
MFSSAr,fj  m3de_Oa*,gf 
•'FSSAGt:  TEWMT^ATIf  *■  . 

0 o C u a t f tff  f: v ; 

sr  irce  : tlS.ppSpp_x  i_tp  aC*_l"',p_f  xpe^^  f nt  . 

T n c n p p " R •' T f P 1 v : ' 

■’PIG  IN  AT  ING.RET'  lPtNFf>  t : 

Tl  S_  P P S P R—  S 1 ,s  S E C T I — UNC  T I M f’ A L_RF  (jUIF-EMLMS, 

originate  g_rf  (jiii re  *f  ’>t  : 

TL  S„i)PSpR.P  aR  AGP  aPm_.5_.2_  l„w_pf  mf  kPm  ANT [ Rf  r 1 1 1 ^E  ' E N T S . 

ImPLF "F MTS! 

VFRSIfNj  TI.S.ITPSPr, 

necuf'Lf  tfp  r v • 

S'*  'P’CF:  T l s_opSpf_  X 1_T  = aCk_LO‘,P_F  xPt  w I ‘'F  NT  . 

PRIG  IN  A T If  G.R*  GDI  PE  ^F  •■  T t 

Tl  S„1>PSF,«-1P  AR  AGP  A Pm_3_  <?_<>_  A_pl-  Nf  T I *N  AL_PEniJTPFnF  ,mT?  , 
hescpIpMi'n: 

" ACTI-inj  SE  n'j  RAqAC  pPpF.R 

INFOR'-.AT  I IN  : RApAP,  r.fHUNOAIT  I f’  A GE  , " , 

I* plf  wf  mts: 

VFRSIPfj  TLS_'.)PSPR, 
t n a c f s r * : 

alpha:  j ■*  t t i a g i /f_s  ^ f p_  P’ 
aipha:  p f r> u d e termination 
a|Pha:  rfemi  j_TF  Rf'iP  at  I f>rj 

DATA;  DM'fP.WEASON 
O A T A ; WE  ASf*  J_F  f*H_()P  fiF 
0 A T A ; Ptm.lNUANT^lMAGF 

Ef  tity_class:  t-age 
E f TITY_r.LASS:  Pill  SF 
E'Tity_type;  orpppf n_ t * age 
Event  : scufuulf 
event:  xri-. 

H_  Y f T:  kE  op‘,!S,oL.TP«.wArAR 
r”yft:  s k e rf_^ 

O'FTl  X M I T _ R 
S r *3  \ e t : fow^fpame. 
nocuTEATEr;  f-y; 

SOURCE  ; TLS-UPSPR_>  1_ t R aC K_L  n ?P_E  X f’C P I NT, 
iNCpFPOR ATFO  I m j 

origin ati jg.pC'JUIweffnt  j 
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U S_orSPW_$lJ~»SECT  Tfif_3_2_-?_fU^CTI«,''AL-.hE(  UIPt^tMS, 


ORIGINATE  G_»Ergul<?E.f!fc'jr: 

TL  S.OPSPW.  Paragraph..  i„  «>_,?_  A_pE.»F"KMANCE_«Fr3i  ii  PERL  MS, 

I MP Lt wF  VT$  j 

VERSION:  TUS.OPSPp. 

TRACTS  T s : 

u r c i s i ^ 'x : trac*_pfrt  «prance_au  ^c  at  i *n, 

POCURfcf  TEp  f'v; 

S r I I«c p 1 TLS-i)PSPRi_)il_TCACK-L''l'P-t  *PE1’ I M(  NT  . 
QP1GINAT If G.^EQUIRE^E^ T : 

TLS.UPSPR_PaRAGPAPH_3.^_^_  l.F  E Nf  t I r*  ' Al..— REf  I'fMfFMf  , 
DESCRIPTION; 

" ACTIn^;55;  SE'lfJ  RaT'AP  rpnpp 

TNrfTH^ATIfl''.  j GHnM  t page  > RataR  (’wpeR,". 

1mple-FvjTSj 

Vf  ?Spf.|  TLS.PPSPp, 
tracts  T * j 

A|  aHA  ! G*'OST_DT:  Tp.fff  IK /i  T I *»N 
Al  PHAt  GM*»S  T..TF  Rfjf  AT  T PN 
A t p H A | I K I T I A C I l f _ S K F r_  P 
OATAj  PROPOSE  ASf,F” 

DATA;  r,Hf's”_IMAG*: 

DATA;  RE  AS  I J_F  ■’R.llP  "’P 

fcA  TIT V— Cl. AS 3:  T-aGT 
e a tit  v__r  u *'  s “x : pui  sT 

Ef  TTTY^TVPf  : OP  U’pt  (,_!»-  AGE 
Event:  SChF_:V'lE 

event:  xrm 

R_VP  T J RPSa',|',Si_T  fl— R A Ni  A P 

P^VET:  3 E ^ 

R_  JE  T : x >*  T T^R 
S~  3p  F T t E:ir"_ERA»e. 
docu*  f n n h v : 

Sfl.tscE  : tL3.orSpr_x  i_tpaCk_u**p_t  xpt  Rp’E ' l . 

INC  OPP  *R  A TF  p I - ; 

IPIGINiT  I . C,_  ^Ej'I-fTfKT: 

TL  S.ppSPR_S'HSeC  T 1 rP_  W_?_FUNCTI  (*NAL.Wf  (Jj  I R’L  *E  K T S , 


OR  I GIN  A T It  G—REQ’  1 1 PE  ‘‘t  'T  : 

Tl  S^nPSPR.PARAGPAPrx^.^-f.iJ.R.E’f  RE  i'RmANCE.RFOI-'IRT  ‘ E! 
iNPLf Ml  jts  : 

: tls.opsPr. 


T5. 


1/1  RSI  * : 
TRACTS  T **  • 

Al  Rma  : 
Al  Rh  A : 

a i pm  a : 


E INO^CRNf  l I C T 

f.Mf*  S T — i)E  T E RE  I K A T I ^ N 

Rfpli  J„pF  T f pi  I K A T I ON 


alpha:  i|p(>ATE  state 


u A T A • Pn 

DECT  si**.: 
Pf'CDNEf  f EP  R ¥ ; 
S'1  IRC f l 


I (i  R I T i 

TPAC*„PeREPR> a n c r _ a c l “f ati-n, 
TlS  PPSPR  XI  TR aCR.L^^T^E XPERT T 


> T 


t 


OR  IGINM  IT  G.RFQUlPt  Mtv  T : 

TL  S_l  PSPR.PA  R Ar,RAPH_i^_?_C_E  I NC  T T Al  _REGi'IR'EPEMTS  . 
DEStf  IP  tion: 

" ACT!'.:  S£NO  RAo AR  oRpER 
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I N F o p 4AT  I ON,  RADAR  oRpER»  ELEVATION  PF  RAGAn  PR[)EH", 
I *pLF ^ T s : 

VfUSIfNf  TL5.DPSPR. 

TRACES  To, 

A|.?mA|  piR^Tl^T? 

41.  Pm  I p 1rh_t  s 

4|PhA,  I%lTI4LT^t_SKFf'_c 

» l 3hii  L',*„ELEVAT”rR_r'E  T F Hf'  I m a t T f-u 

4i  Ph/>  j '.TER  M'-Al  T~‘ 

C A T 4 , l p ele  V 4 T I .IF 
fcF  T I T v— CL  ASS  : I^AgE 

E * r T T v_r  L 4SS  I pUl.Sf 
£F  T I T Y_T  *P£  : pSPPPE  n_I^AGt 
EVENT:  SCHEDULE 

EvEnt:  xRh 

«_NET|  RESf'^^SE.Tn^Rioipr 
W.MFTi  S*E')_W 
P.'JET:  XHp~R 

Sl'c3>f.T;  F (*  R X_F  R A *'£ , 

0 0 C U F E f TEH  P.v  • 

So JMCE  5 TlS.OPSP^X  l_TRACK_L,'',P-EKPE^I“f  m . 

I n c e f p * * 4 t f d in  : 

"PIGINATIMG_pE  } ! J J R £ R f NT: 

Tl  S.nPSPR.SU^SEC  T I OF  _3_?_2_F  UNCT  I **  A| Rf  t. U I RE Mk  F T S , 

ORir-IF  A T j f G.^F  U 1 1 T p E Mi  '-T  : 

TLS.t'PSpP-p4P4r,PAPK_t3-,3_^_C_Pf  F Ff*Rf‘4Nrt_PF  Ql  JR£MEUTS« 

Implf "ents: 

vFRSinr.:  tls.ppspr, 
oocufe f ted  hy  : 

SOURCE  : TLSJ'JPSPW_M_TfiACK_l.f>!,P_f  xf  E e I f’E  fj  T • 

OPIGISaT  It  G_PEOUIKEk,Ef-T : 

TLS..DPSPW..P  aWagP  AFh— 3_?_£_[)..Fl  nc  T T P‘-  a I _»EOU  I RF  MF  NT  s . 

DESCF iPTIpMl 

" ACTIRfjj  S E '■  0 RADAR  PR  pE  R , n£TE««lNf_lf  ACF_Fl  EVAtION 

information,  p'Af  f,  elevation  if  im7ge  , ratar  prder, 
T«Af  Sr  T s s T ^ TIME  pf  »a:.aR  '“RDEE", 

ImPlf^Emts: 

V F -» S I <"  i - 1 TLS.uPSPp, 

TRACES  To, 

alpha:  IN[TIALm_5*tn_R 

alpha:  L ' ^f-LE  v a t“p  \i_r  E T FRR I N A T I "n 

al  pha  : l^>’_TEr,,I‘  at  j p» 

alpha:  i j®d  a tf  — s t a tE 

data,  f'PPp_PEASPM 
0 A T 4 , PE  AST  '_EOk'_pR  PF 
t n T i t Y— r L 4 SS i Image 
t h r I T y_C L A S 5 : PULSE 
EN  T I T Y_T  Y‘*E  ; ORPPPt  P_  IMAGE 
EVEMTt  schedule 
EVENT:  x«h 

R_VFT:  RFSpO',SE-Tp_r  adac 

w”^FT,  S*<E.  r'..R 
R~VtTl  X H I T— K 
Sl'HNf  T : FPRm_FBA*'£  . 

DPCU»  t F TF  f)  lY, 

SOURCE:  TLS_0PSPB.X1-TRaCK.L«BP„E  xPepImE  A.T  . 
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INCORPORATE!;  I*'i 

''PI Gif': AT  ING.PE'ltilPf  (--EM  , 

T l S-DPSPP-StJHSeCTIoK_l_?_?<_fUNCTI('flAL.PE  (•  U I RE  Mt  N T S , 

ORIGIN AT  If  G_RE  QUIRES  NT  j 

TLS.UPSPR„.PA^AGPAPH.3«.^,2_0«.P{  BE  f R»'AfJCL„DetJt|Iwt’“E^TS, 

IfPU  ME  J T S I 

vr«SIf^i  TLS_[)PSPR, 

DPCUF  E NTf  f)  H v j 

SOURCE : TlS..CPSP»_X  I_tRaCo_L«'’P_EXPEbI‘'E  NT  . 

OP  I GI  NAT  If  G_RE.G'JIPEMEN  T : 

Tl  S„.DPSPR..PaRagPaph.3_2_2_E_FI  NCTTPNAL.PEGUIRE  MEnTS. 

DfcSCP  iPTIfiG! 

"ACTIO*:  DROP  TRACK  on  H A k.'  ft  V f R ImAGE, 

INFORMATION:  PROP  TRACK  C?  M f.  S S A G F.  , PAPAR  ORfEK,  TRANSMISSION 
T I MF  OF  RADAR  ORDER, ", 

IMPLF  “F  'JTSl 

VF  R S I o *i  j TLS.OPSPp, 

TRACE  S To, 

a I 3 m a : i n I t i a l I Z E_  S * e n_  p 
a l p m a j te;rm_ track” 

Data,  npop^RE  as '*N' 

DATA,  FNTp”_T IM£ 

JAlAj  R£  A S o ’J_F  o R— pP  or 
E.F  TITY^CL  ASS;  I m"gE 
EMITY.Typf,:  ijPOPrf  D jiflCiE 

EVENT:  SCHEDULE 

EVENT:  XPH 

HE  3 S A G f : TERN  IN  ATI  Pm 
R_NtT:  CC_«ESP?nSe 
T ; SK E * —R 
W„'JET:  X H J T — R , 

DOCUMENTED  mvj 

SP  JPCE  : TLS_DPSPR_X1_TRACK_LO0P_FxrEPlMF NT , 

TNCOPPP R A T F I * IN; 

OP  IGI"AT  ING.'TFDUI«Ei'E  nt  : 

TlS.nPSPP.SUMSEC  T I '!  _3_2_?_FUNCT IONAL.HET UlRt  men  TS , 

Qp  IGI  N A T p G.RFQH  I PE  .Mt'  T! 

Tl  S.DPSPR.  pA  RaC.caPh-3_2.2_E_PE  «F  or  m ANCt.Rf  HU  I «E "E NT  S , 

IMPLF mE  jts  : 

V F R S I 0 ‘ : TLS.Uf’SPp, 
p o c li n e ^ Ten  i»  v : 

SOURCE  I Tl5_0PSPP_x 1_tPaCK_loop_F  X PE p INF  NT  , 

OP  I G I N A T I NG— pEfiU  I r?E  ME  N T J 

TLS.DPSPR.PARAGRAPH^i.^.i.  A_fI  *JCT  I ona|  _RE0UIRE  UFnTS. 

nESCPlPTI-fij 

" A C T I 0 f : ‘ . A I ' J T A I ,\|  TRACK  ON  I *AGF 

information,  jf*Air xf stImate  or  state*,  radar  return, 

TImE  of  laST  PROCESSED  RETlRN,'*, 

ImPle  Mf  MTS, 

VERSION,  TLS.OPSPR, 

TRACES  TO, 

ALPHA!  T1_T2-t0EASuFFVFNT_E*TBArTI0N 

aipha:  T j"n.  f a sure,  men  t Extraction 

ALPHA;  UP~ATC_STAtE 
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DATA;  STATE 

DEC  IS  I CM  J Sy\CHh?«NeuS_v YNCHR^'^ijS^Tf  A(.K 

fcNflTY_CL*SS:  I M A qE 

ET  TT TV. TYPE  I IMAGt.IK_TRACK 

R_HF.  Tl  RE!)p^,J5E_Tr'_WA”Af.  , 

doCunen'Tfd  fy: 

Sc  JRCF  t TlS..OPSPR_M_TP  aCK.L'V'P.F  *PfcR  IMf  M , 
INCOFPCRATFD  IN| 

■YRIGINATING^RE  IUIOl^EM  ! 

Tl  S_DPSPP_S"P5FC  T r V -3_2_^_FU*'JCTIflNAL„wer,lJI«t  -t t ^ T S . 
CP IG IN AT  u G_^E  QU 3 »t w l M » 

TL  S.0PSpR..pAPAGPAPH_3_,P_*_A_pf  Rf  f'RMANrt_RfDi'IRt‘/t'-TS, 

I M P L.  E y F MSI 

VfffSICNt  TLS.cPSPp. 
trace  f r c ; 

DEC  I ST  ON  I TRACK_P£  RF  OPR  ANCE.ALLTT  a T I ?1\  , 
nccuf  Ef  TFD  fs  Y ; 

SC'  IRCF  : TLS.0PSPW_X)_TRAC  K_Li,1P_F  y p t p I *•'  F NT  . 

ORIGIN  AT  If  G_-?EDl'HEuEM  J 

TLS.DPSPW_PAPAGPAPH_3_^-3.:i_F  l N c T I 0 N A I _REr>l)IWEMF  N T S * 

DtSCFIDTI«N; 

" A C T I *1 M | DR^P  r'ACMiRf  ri'M'ANT< 

r-F  OPR  at  J sin;  REDUNDANT  ICAf.r,", 

Ii-plf  jfvts: 

VERSION;  TLS.DPSPp. 

TRACES  Tf'j 

AL  PH  a 5 RF.D'TJ.OF  TFrMaaTicn 
ALPHAS  RFO'I^TFR-tNATTC'f. 

Data*  p t d lj ’ p a j t _ t ^ a t; f 
tc  T I TV^CL  ASS  S W.t;F 
E>  T1TY_TYPL«  OP'IPf'F  n_  T age 
H?  _ M F.  T J RFSPflNSF.^Tn.RArAt:  , 

DOCUMENTED  F;  v S 

Sc  IPCF  : TL.S_DP.SPR_*  1_tr  iCK_L  CMF_f  *RF  R L^f  c l , 
INC5FPCRATF  I.'  If'S 

or  I GINAT  ING.PF  DU  ire*-  F NT  : 

TLS_DPSPR_S''t'SECT  lpM_3_?_  <_F  unC  t I O',  al  _rE  ru  I Rf.  *EN  T S , 
OF  I GIN  A T If  G_PEQtl  l RECENT  : 

TL  S„DPSpR„pAR  AGPAS’H_3«.<?_i_H_pF  RF  RfiM  ANCfc_WF  rjDIPt  Nf  MS, 

1 M'P l” '"T  USl 

VFRSICNj  T L S— Up SPR , 

TRACFS  TO; 

OF  C I S I ON } TRACK-PtFFnPt'ANCF_ALl  OCAT]*N, 
documented  h y : 

sc  irc e : tls_dpspr_*  i_tp ACK_Lcar_F  xpewirem, 

OPIGINATIF  G_RE  DU  I RL  ’’E  m T ; 

T L S_DP  SPR_P  A R AGW  APr»_3— 2_  5_C_F'  NC  T T f*N  AL.^EOl.i  I KE*E  nT  s . 
DESCRIPTION,: 

" A C T T C f;  | liRnP  I ^ A C F *r>CST< 

INFPPVATiPNt  GHOST  Image.". 

ImFLE  ^ 'ITS: 

VERSION;  TLS_DPSpR. 

TRACTS  TOj 

ALPHA:  G‘UCST_DE  TF  Rf' IN  A T I CVJ 
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Al^MAJ  GMftS  T.  TF K F A T J 
i)  A T A • r.HTST.I  ■*  * tf 

fcf  riTv.ciAss:  I*ac,f 

tf'  TIT  Y_TYPL  l ORflPpf  r^I  V ARE 

w.^fT:  PF.SP^^sr.T^wTriAf- , 

OflCijFEf  tfp  py  ; 

Sr»JKCf  J Ti_5— DP5PF*_x  l_TK  ArK-L('J'P_P  xf'T  >-1*  ( n 1 . 
IhCwPPrVATFl'  I *■' : 

5P  I G I N A T I NG— RE'JO 1 F t.  ^ F A T 5 

U S_nr5pt._51.MStC  II  nf  _^_?_3_FU*“CT  I l lPf  it  MS  . 

ORIGINAT  I^G-.'*EfiUIHtWlfcNT! 

TLS_t'PSPp„PAPAr,RAP»  i.C.PtPF  fC^AMrE._«F  C0UIPF.‘>  MS. 

ThP^T  -T  j T S : 

VFRSIGf  J TUS.OPSPr, 

tracfs  r ft  j 

Of  C I S I *f'  : rRACK_Ptt,F^P>'A',CF_ALLf,CATl«N, 

0 C C U f E N T F P f> y • 

Sr  IPCF  I TLS-nPSPR_>  1_TP  Af.K_l.MP_f  xpT  Rp‘f  M , 
O^IGINAT  If  G_RFrj'ilGt  Mt  4 T I 

Tl  S.OPSPk^p  aR  al,k  a f>h_  }_<>..  O^F l fJfT  T «n  A I _REOU  I R fc  nT  s . 
nt  SCP  iT’MriM 

" A C T I ft  ^ : 3F‘0  pir-Af'  ^RpFR 

I N F f P F'  A T Y fi  N I R A P A P P«r>FW,". 

1 m p l r *•  f *j  r s • 

VfRSI'V.j  TLS.OPSPR, 

traces  r ft : 

A I Ph  4 ; A S S I GK  „w  A f F 
A I J h 4 • JNI  T I \L  I ZF  _S*f  p_R 
At  P h 4 j v At\F  _4H  :'C  A 1 I nf; 

AIPhA;  mA|.F.“c  V^AnT 
At  Pha  • PICO 
aiPmA;  SFLf  c t_C  AMy  anc 
At  PHA  : SF  T_l.  AST 
E P T J T y_CL  A SS  s Pi.IL  Sf 
EVE M s SChEiHJlF 
EVENT*  A R Ft 

R_MET;  r ft N( T M ft U—  R F Sf-ORCFS 
r_ntt:  s*<tP_R 
R.METj  X’'1T_P 
SI  <NET  S FIG  J_FPA«t  , 

orCuA  Tf  n h>  j 

b ft  . I o c F S TLS.OPSPP^X  l^TP  AfK_L'Ti,P.EXPfc  °IA|  NT  , 

I M C ft  F»  p ft  '■?  A T E t ■■  IN; 

ip  I r;  1 *i a t ing.f<E1i.'Iwe^T  nt  : 

Tl  S_r>P5PF'_SH»Ser  T r nF_3_P_3_F  UMC  T I f*N  al_re  uji  PL  11E  f T s . 

OR  I(,IN  A T jf  G_RFijhI  wf  »fc  n T : 

TlS»OPSPw.PApAGF<APH_i_<?„i_l).PF  pF  f'F^ANf.fc.WF  HO  l pL  '’fc.M  S . 

ItipLf  *E  Ms: 

vr^SpNj  TI.S.OPSPR, 

TRACTS  TAj 

OFCISIPNi;  TRACK_rrFF  «F'VAMCT_ALI  pf  ATIPn, 
nflCU‘ENTFo  my: 

Source:  TlS.OPSPK  X l _ T P a f.  K_L  * *P_f  XPfBjkiM, 


OR  I GIN  AT  If  G_*EfJilI  we  ,,t'“ T ! 
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TlS_DrSPR_PAPAGRAPM_J,.?_3_E_E  l^CT  T^N. AI. RtOilTkft  -'f  > TS. 

gescr  i^rifiN* 

"acTium;  SFN'j  r a p a b <*HnER 

I^F  fPMATinut  RApAR  f'kPtR.". 

I hP^E  MF  ^ T s s 

VERSION*  ILS.PPSPR. 

TRACES  T K 5 

A l Pm  A 1 FT  fP_C  INF  I ITT 
ALPha:  f 1R“™T 1_ 

At  Pm  A | F r'l<-,_T  S 

alpha:  I'JlTlALlZF.SKFr.P 
alpha:  makE-C^^,’AnC 

alpha:  p 1 c KZr A^OIpA TE s 

A l pH  A | PTCk_C">,mAM 
A i Pha I ST  LF CT_r T*MAt r 
MESSAGE:  T 1 __  T C ^ ‘‘H  A fj  n 

RTSSAGL:  TL.Ci^'ANt 

r_nft:  s*lp_R 

R~  Nlf  T : X h I T , 

DftCuFEf-TFn  f- v : 

Source:  TLS.OPSPR.X  1_tRaCk_LO0P_FXPERJ,-,E  M , 

INCORPORATED 

0 R I G I N A T I n r,_RE  1L  I '«  i f E K t : 

TL  S-pPSPR..S'|,,SeCT  MA-3_P_i_F  U*.'CT  I "NAL.REf.UIPEMtMS, 
OR'IGP-ATp  G_Rf  Q < > I P L ^ C ‘ T; 

Tl  S„l)PSFR_P  a BAQR  APh_i-r?.i_E_PT  pf  r»K><ANCE_RE  iit)lKt"EsTS. 

IMPl”  jT  NTs  : 

ve  ps I Of  : TLS.OFSFR, 

pncuft  f te  o t-  v ; 

S l"  J R C F.  : TlS^OPSPR^X  1_tR  aCk_l^'TP_F  < p t R I M E n 7 , 

OR  IGIf.AT  p G_Pf  0 * 1 1 Ai L “> t.  NT  ! 

Tl  S_PFSPR^p  A R AHR  aph_3_P-3_e-e  E T I "h  AL^REPiJT  PF  he  nT$  , 

Implf’jE  JTs: 

VE  R.sr’’  : TL-5.TPSPK. 
traces  t^ 

alpha:  nf  -t  '»  r 

JE  SS AGE  : T l_T<>_BF  yi  p\ 

MESSAGE:  T 3„R  E T JPn 

P_'IFT:  PFSP',,'lSEi_T0_PAr'Ap 

Shhget;  h I SS  T JG^r'e  TmrmS  , 

DfiCu^EFTEn  Rv; 

source  : tlsjjpSE’R^x  i_tr  aCk^loop^fxpe.pi^e  nt, 
IMCPRPOR  AJFO  r.j 

ORIGINATING^ RE  3H  I RECENT  » 

Tl  S l)PSPR„S'IHSEC  T I «F  3 t 3_F  IJNC  T I 0 N A |__Rf  U U 1 K t Mt  E T S . 


ORIGIN  AT  I A G_RF  CHI  I PE  “E  NT  : 

TL  S_l'PSP  R^p  A R A Gc  APH^i^c1^.^ C’  _PL  R F OR m ANC  E.RF  Ol1 1 R'E  ME NT  vS  , 
INFIE  ^nts: 

VERSION}  TI.S.OPSPR, 

DOCU^tNTFP  Hvj 

s»  IRCE:  Ti_S_OPSPR_x  1_TR aFK_LOOP.F  XPER’P’F  NT  , 
QRlGINAt  IKG.PFUlilRk  it'  T: 

TIS.L/'PSRR.Pa  ■»AGRAPH-3_P„i_G«.Fl  f f T I ftN  AL_RfcOll  I RE  RE  NT?  . 

I HPL.7  RE  RTS! 
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VERSION}  TLS.OFS^R, 

TK*CfS  Tfl, 

*lpHA:  T.JE  TE  RP- TN  A T i *N 

A l On  A J Lfl^ElEVAT  jPN_rf  T F 1 1«  A T I ^ N 
AIPna:  HP  Ij'IN.OE  TERR  J K A T J 0* 

A L pN  4 j TEH^.THACK 

E^TITy_CLASs7  twAr,f 
E>  riTv^Trof  : P age.. in_trac*  . 

OPCU^t^  rtf)  h v • 

Source  i tlSJ)PSpp_>  i_tcaCk_l'’?p_F*pEbImpm. 

INCORPORATED  I’.j 

OR'IGINAT  I NG.wtOL  IHf  p p a t | 

T l S.pPSPR.S'-MStCT  I f*K_3_?_*_ruNCTirriAL_WU,IJlWtMfc  MS, 
0»IGINAT  IP  G..HP  culKf  m*_nT  l 

Tl  S„D PSP R.PaR AGRA ph_3_<?..3_G_pF  HP  nKMANCE.PFni-'lHtMEf'MS, 

implf  -F  ns : 

vF  R$I  CP.  i T I S.^rSpH  . 

COCtJPfcP.TFD  F1  V } 

SrJHCt  5 TLS_OPSPR_X  1_TC  ACK„L,,f,P_E  XPF  H'lMf.  p T . 
PRIGINATIF  G.PEOUIPt^E'-T  t 

TLS_DPSPR„PA?AGP  APh_3_<?.4..A_FI.  -<C  T I fU-Al  .PtnillHEP'F  NTS  . 
description: 

"ACTIOS:  “aTNTaP,  f s t J m * t e op  H a (i  A R R E S 0 11  R [.  F S 

I N P 0 R M a T T 0 x 5 H'aPaC  RpSOl'PCE  USAGE  ESTIpaTE,  R A p A H 
ENERGY  fSTI  -1ATP  , UPPER  hound  ESTTmatF.", 

Implf  *F  ns: 

VERSION?  TLS.DPSPR. 

TRACFS  TO; 

alpha:  DPpP^PiJLSf 

At  Pha  : SE  T.CO'JNTF  D 
alpha;  S E I _ S u ‘J  M F.  D 
alpha;  sn»lE.''EPGv 
alpha:  suh.us agp 

EK  T I T Y_C  L “ 5~  S Pl'l  SF 
R.VET:  cMMTROL_REsf  UPCFS 

h'-iFT:  mahar.sI'mhae  y 

subnet  « SII'^PETUPnS 

S 1 1 H n E T : TALLV.PtTuEMS. 

D nc up- t p tfp  py ; 

SO'IBCF  : TlS.OPSPR_X  1 _ T K A CK.L  0 OP_E  X PF.  R I HF  NT  , 
INCORPORATED  I*-: 

OR  I G I N A T I N G—  W E T t • I b E P" E M J 

TLo.DPSPR.S'lPSECT  IoT_3  2 u.E  (JNC  T I ON  AL.I’F  Gl!  l REmEN  T S , 


ORIGINAT  IP'G_PEGUIHEMENT : 

TLS.DPSPP.P  A RAGPA  Ph. i.^_'4_A.PE  op  nh»i  ANCE.HFQ1 1 1 PE^E.NT S , 

implf  *e  nsi 

VERSION,  TLS.OPSPr. 

DflCUP'fcE  TED  PV: 

SOURCE:  TlS.DPSPH  X\  track. L"’|5P_E*pERlMt  M . 


QRIGINAT  IP  G.PEfHilRE^F.GT  : 

TLS.DPSPR.PARAGHAPH.3.a.4.H.FLNr T TM-Al _REOU  I RF  MEnT s . 

DESCR IRTIOn: 

"ACTION}  ALLOCATE  PAL'AH  orders 
I NF  0 p y A T I 0 N J RaEAP  ORDERS#  IMAGE,", 
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IMFLME  mts: 

v E R S I n j TLS.OPSPp. 

TRACES  T"j 

Alpha;  ASSlGN.KATt 
alphas  C^E ATL.STATE.FTLE 
alpha;  d°i,'p_L“ist 
alpha:  hake”all^CaT  io», 

CFCIST^.':  ^AOAF_Sc^Fni:LE«_Pf<I^PlTI?AT 

fcMTTTY.CLASS:  PULSE 

R_NET;  CflNTP',L„Pf  SOURCES. 
documented  py : 

SOURCE?  TlSJJPSPH_X  1_T«  ACK_L'l,JP_f  XpE  pI!-'f  NT, 
InCORPORATF P IN; 

flPIGINAT  ING.Rfcdll  IRf^EK  T : 

TLS.nPSPR^S'MSEC  T Id  K„3_2_«.P  UNCTION  AL.Rtf.U  I WL^EKTS. 
(SPIGINAT  ING.RF  CJI 1 1 W t m t r.  T : 

TL  S.OPSPR^PARAGR  APH_3_?_a_H_pf  Pp <*Cm  AMCE.RFnu I R't ‘‘t NT  S , 

inscription; 

"I.1PSPR  PARAGRAPH  3.<?.R(R),  RESOURCE  f o f J T R 0 1 , STaTFS  THAT 
('THE  OPS  Shall  ALLOCATE  PaPa*  Commands  SO  T : a t NOT  howe 
ThaF  (TJD)  J^ULE.S  APE  C AfT^  r»  PfR  T h AGE  , MOL  t'Ot-c  than 
(Tar)  KlL^ATrs  ?R  (THd)  P('L?f  S/SECOnd  for  all  IMagFS  I* 
TRAC*,  ' )". 

ImPlF^e  J t s : 

vFRSI^k;  TLS.''pSPp. 

TRACE  S TO; 

DECISION;  RaDaw.ReSoi  pCE_CrNT»ol_M 

OFCISIfn:  R A 0 A R~  R E S 0 l o G EL_C  ^ N T M d L Z ^ ^ 

Pf  RFOR"  ANCt.REGG  IRtf  E N T : ENEWGV_f  F R_Tm  A(,e 
PF  RF  OR"ANCeZrE.,j1i1Wf.  rF  NT  : P 1 N S F S^P  E R„S  C C ON  l 
pf.rftrn anceIre  juiret'Fkt:  radi atTp_p"‘''F.w 

VALIOATI  0n_~  a Th  : c ANpl’VF  R_c  *'"K'AHD_  I M UT 
VALIOATI0!i_PATHj  R A P A R_  C O M M A N (.)_  n • I T P 1 1 T 
VALIDaTT'-'ZpaTh:  RArAwZwAVEFORr_rprHERTiLS 

vALTr»ATia'-“p-»lN.T ; ( ?_ i™ a GE„h a Npo v FR 

VALIOATI  d'~P  o I J T : h A?  AR_rflMMANP_(di|TPilT-FOr;T 

valtpatt  v.ZppImt : st artYng.poim", 

D 0 C U N E N1  T F P I:  Y : 

S"owcf  : tls_opspr_>  i_tr aGk->l|v,p-f xpf r iMr  m. 
ORIGINATE  G.REQUI RE VE‘T: 

TLS.OPSP«_PAR/r,PAPH_i-a-S-A_F  L*  n Inl-AL.Rfc'CUJlRE  HFfjTs. 
descpipttpn: 

"action:  dLiTPIJT  Tr  PfRmANFNT  PILE 
INFORMATION:  Tj^F  f*F  APPEAPANCF  OF  C2  I E S S A f L * 

HANGOVER  I m A G E (ISTJOaTEO  STATE).", 

implf  *f  ns: 

VERSION:  TLS.PPSPR, 

TRACES  Td; 

alpha:  TRaCk.init I ate 

NTSSAGE:  TRACK.INIT jATldN 

R.  NT:  CG_RE  SPOnSf. 

D " C U K' E ^ TFP  L<Y  ; 

SO JRCF : TlS^ppspr^y i^tRaCk.loop^lapeRihe NT, 

incorporated  r>* 

ORIGINATING. REGUIRe^T NY  | 

TL  S.DPSPK.S'JtfSEC  T I(iF_3_i— ^.FUNCTIOf  Al.RECU  1 RE  MtK  T S , 
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ORIGIN AT ING.PEQUIRE T t 

TIS.DPSPR_PAP*GPAPH_3_2_5_A_pE  PF0RmAnCE_PEGUIPE',ENT  S , 
iMPLf  M[  JT S * 

VERSION:  TLS.DPSPR. 

OUCUPET TED  HYj 

SOURCE:  TLS_DPSPR_X  1_TR  ACK_Ln,TP„f  X Pfc  « I MF  M, 

ORIGINATIKG.PEOUIRE^E'yTI 

tls„dpspp_pa'-?agpaph_3.2_5_b„fl  NfT  I 0‘JAI  .reouIbements, 
DESCRIPTION; 

"ACTION;  fl'lTPi.JT  Tr  rEPMANFNT  FILE 

JNEO«matTONj  T^E  *F  DROP  TP  AC  K , REAS^I  FOP 
DROP  TRAC*,", 

IMPLEMENTS: 

VERSION;  TLS.DPSPR, 

TRACFS  T 0 : 

a i p h a i GHnST.nETERf- ikaTi«n 
aipha:  r,HciST-TrR”iNATT'"f. 
alpha:  l^^.EI-E  • at  jr '^nE  te  rmina  t i nr, 

alpha:  — TER^InaT i ” n 

aipha:  RELIIJ^OETFhm  ikaTjON 

alpha:  RFfuiN.TLR^iT  at  jn, 
alpha:  SET_  TRrip 
aipha;  ter*  _track 
t* t i t y_t vpe DRnppf p_tkaGe 
MESSAGE:  TrACk_TFRF  INAT  prj 

w_  JET:  cc.PESPfNSt 
P.NET;  PE.Sp,NSE_T  T.papar 
S 1 1 B N E T : R E C n R D_  D Et  p P , 

DOCUMENTED  BY; 

SOURCE  *.  T L s^DPSPR_ X i TP  Af.K_Lnnp_E  XPEP  I*'f  M , 

INCORPORATED  IN; 

API  GIN  AT  I HCj-Rf  °L’  I Re^  FM  : 

TL  S^DPSPR.S'JRSECT  Ifir._3_P_S_FuNC  TI  nNAL_REDUIREMLT  TS  . 
0«IGINAT 1 f G_REnUIRE  4FNT : 

TLS..DPSPR_PARAGR  APH_i_^-S_Bi_pE  PF  nRt' ANT  E_Pf  HI1 1 PE  ,V,EB  T S , 

ImPlE  m F n T s : 

VERSION:  TLS.DPSPR, 

documented  by; 

SOURCE  : T lS— l>PSPP_5i  1_TRaCK_L"?P_EXPEWIwE  kM  . 

ORIGIN  ATI  N-G_PE  DU  I R t <E  N T : 

TL  S„L'PSFR_PARAGRAPH_3-2_S.C.FLNCT  IflNAL.REDUlRFMENTS. 

DESCE IP  tion: 

" AC  T T ON  ; Output  to  Pe»M  AtJF  NT  PILE,  UPDATE  S T A T p 

information;  Image  state  estimate, ”, 

IMPLEME  NTS; 

VF PS  I ON | TL3.DPSPR, 

TRACFS  TO, 

alpha:  f or-_uPI.)ATe 
alpha;  SET.PULPE 

al  PH  A : T 1 — T h f A SijREMpN-T— EXTRACT  ION 
alpha:  t3J'EAsi'REmEnt  Extraction 

alpha:  i ip™  “ T E —S  t a t l 
tf- tity.cl^sS:  pulse 
E>  tit  y_  type:  RE  TL'rKF.D.puLSE 
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f-  f 5 S A r;  E I STATt.UPpATF 

R_JETl  wr.Sp^NlSF-„Tn_fv  AOAK , 

DOCUMENTED  Fvj 

Sr  iPCE  J TlSJ)PSPR_x i_tRaCK_L*5P_E  xPfkiMFKT, 
INCORPORATED  IN} 

ORIGIN AT ING.RE 3 U I P t f ' L K T « 

T l 3_DP5>PP_SNPSEC  T I nN_3_?_t>_F U’JC  T I p N A l_WE r. U 1 Rt  “EMS, 
ORlGINATp  G_«t  OUIPEwENT: 

TLS_DPSPR.PaRagRaph_3_2.5_C_p£.  RF  r»R n ANCE.RFCi 1 1 RF  “E^ TS  , 

IHPLP  me  USI 

VF  H$  I PM  TLS.DPSPr, 

DOCUMENTED  PY; 

SOURCE!  TLS-PPSPR_X  1_tR  aCK_LPPP_E  XpEKlMf  M . 
ORIGINAT  p- G„^EOIJIpEf‘ENT  S 

TLS.UPSPR.PaPagRaph_3_2.S_U.fL  NrTlOvAL_REGUlRFMENT$, 

OfcSCR IPTIPH : 

"acttom  output  to  f^ma^'imt  file: 

INFORMATIVE  RaCAR  KfSpi'RCE  USAGF,", 

IKPlF  Mf  MTS  t 

VFRSIPNj  TLS.OPSPR, 

TRACES  TP: 

Alpha:  C,f‘pLETE_Suf  H4PY 

a^pha:  qbop^p jl3e 
a i R h a : SE  t _ 3 1 1 >1  h e n 
Al  PHA  : s1  II'.'  IS  A GF 
TITV.CLASSj  Pui SF 
EN  T I T y_t  YpE • RT  TURf-£r:_PuLSF 
EVENT:  summarize 

HF3SAGE:  »,'AI)AR_USAGf 

W_MfT:  R AUAR_SI;MM  A(.  Y 

Subnet:  s * i *■'_  r e T u R n S • 
documented  p y : 

SP'RCE  J T | S_f'PSPR_>  1__tC  aGK_LPPP_T  *PEpINf  M . 
INCPPP^Ratf  m in; 

PF  I GI  NAT  I r;_KE  J<  ■ I R£.T  T K T ; 

Tl  S-OPSPR_Sl'HSErTTr»F_3  e ^_T  UNC  T T r"  al_RF  i.U  1 RE  H T T S . 


ORIGIN  AT  IT G.RF QUIRE  "F“  T t 

TL  S.I'P SPp.P  A RAGR  a ph.  5_P_3_i,_Pf  RF  "Rt>  ANCE.RF  U1  I pt  “E  NTS, 

I mPLF  yF'lTS! 

VFRSim  : TLS.UPSPw, 

OOCUNEnTFD  U Y ; 

SP'IRfF:  TLS_nPSPR  M TRaCK_L"',F_F  YP&R'IHM.T  , 


OR  IGINA  T IT  G_RF  fil/TPt  '<(.  T : 

TL  S_UpSPR_SFCTIn  N_  3_P_F  U JC  T I ftf.  A^  _RF  QUl  RE  hf  NT  S , 

ImPl”"^  NTS: 

Y F R S I P t : TLS.UPSpP. 

TRACTS  TP: 

SUBSYSTEM!  jSC  2 

SUBSYSTEM  sspfrmel 

SUBSYSTEM  SSRADAr, 

Docu‘Ek  tfd  Dy : 

SP'JRCF:  TLS.OPSPR  XI  TR  ACK_LPPP_F  XPEPIM  NT  , 


ORl&INATlTr,_REGUlREMt,;T! 


H-63 


1 


TLS.C'pSPR.SFCT  I 0\_3_<'_pE.rF ORwif  CF.rF  tJ|ilPfc.MEr  TS  . 

IMPLfc *F ^ts : 

VMSIOMt  TLS.TPSPR, 

OOCU’'  t-MCn  F'V; 

SOURCE.  . TlS_OPSP«_)i  t_TR  ACK^LOTP^E  XP£«I*t  M , 

OR  I G I Ni  A T If  G_R£  QUIPt  *■  r.i'T  ; 

TLS.t'PSPR.SlCT  I "if  _3_l„FU  JC  T T Of.  Al  _Pf;iJUT  RF.-tf  NTS. 
iMPLf-  n ^ t s : 

Vf  I * TLS.3PSPR. 

TRACES  TO; 

Sl'aSYSTFf’J  SSRADAr  , 

GOCUF-tt  tf  n r v : 

Sf  IRCE  5 TlS_OPSPR_X  1_TP  ACK-L(,,^P-FXpE.Rl’v,f  NT  , 

OR  ININ  a T If  g.wf  rjni  PL  'L'  T : 

TLS.UPSPp.Sf  CT  ION_3_t_PERF  '’“m  A f.C  f.prfJt ; I R t MF  r'T  S , 

T-PLf  ■•f  NTS  : 

VFRSinr  : rLS.OPSPR. 

T f.  A c f s T n : 

SUBSYSTEMS  SSRAOAp, 

OOCijF'ENTFO  By; 

S«  JwcF  : tls^i*psp»_x  i_TPdrK-Lri',P_FXPfcRif'f.  NT , 

OR  ININA  T Jf  T : 

TlS.uPSPR.SE  CT  I~t  _3.c,.r">'CT  T Of  tl  _Re  ‘^IJTRF  ^FMTS. 

IRPU  "f-  NTSS 

VFRSIflt.  TL3.0PSPR. 

InCOFP PRATTS; 

op  i r,  i n at  i mg.pf:  qu  i W£F  f f t ; 

Tl  S_DPSPR.S'JPSfc  r T T.r  P 1_TU  xCT  I«f.A|  _RF(.UIR£M£N  TS 

OP  I GIN  AT  i”i.;.pe.niiIR>  fTms” 

ti. s-r)PSPw_S',Rser tiot_3  p e*  unc  t i on  al.re guire^lfts 
•ip  IG I NAT  i”g_PEOUI»E  f EF  7 ; 

T I.  S__ [i P 3 p S~ ^ SECTION ^3  £ 3_E  UNCTION' AL_R£t,iUlRE*EKTS 
ORIGIN  AT  l’,.RE  JUIR'E  f Tnt 

n S_>PPSPP_Sl,PS£C  Tint  _3_?_  J_E'LJNC  T I on  Al.RF  r.  UI«t  ME  F TS 
OR  I G I N A T I -(,.yF  11  I « E F (T  f-  T : "~ 

Tl  S.r)PSPP_S"BSECTT  of_^_?_S_funct  I ONAL.PFWjIRt^-MS, 
T W A c E S TO; 

I T Pl'T.I  N TF.pE  ACE  l R*r'At_r’“ 
a 1 1 T p UT_  inTOTACE  ; P A r a R 'TUT, 

OOCUPEtTEP  E'  Y ; 

So  J n c E : TLs.npspR_x  i_tp  ACK_Lnm''_t . xPtB  I*  F '-i , 

ORir.  INdT  I E G_-J£  Ql  i 1 R£M£  m T J 

TL  S.UPSPR.SE  C T I 0 N_3_c.Pt  RF  OR  m A F _w£ OU  I REf<F  F T S , 

Implf  -FUj: 

YF  R S 1 1*  ►.  | TLS.uPSPR. 

INCORPORATES; 

TPIGINATI''f,->PE:illiIPtf'F  F.TJ 

Tl  S_nPSPR_Sl:dSEC  T I Ot  _3  l_P£  K F OP*  A NCE _RF  Gl  I H £ t*  F.  N T 5 
opiGINATl"r,.RE0UIWEFrNT;" 

TL  S.fiPSPR.oU'TSFC  T I 0N_3  ?_P_PFRF0PtA>  CF_R'f  «U  I RFF»£  NTs 
OR  I G I N A T I N G. P C J U 1 f ' t f-  ” T ! ” 

Tl  S-CPSPP.S"PStCTI  Of  3_E,tPFORM A MCF_Rf  Q U T R £ !•'•  E N T s 

OR  I G I F ATJ  NG.Pt  ’’JU  I P£  t ”n7  ; ” 

TLS.DPSpp.SULTSEC  T I OF  _3  p R_pEMFORn  ancE_PE  QUTRENfcNTs 
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I G i M t i 3 1 i p f f f- m : 

T I S.[)P5.PK-c>ii.3Sp.C  T r of  _}_2_N_Pfc  PF0P'>'A\iyF_PT  G l I P E. f f"TS 
DOClif  fc  f T F R h v ; 

S*  JB’CF  ! T(_5— i'^SPP^X  1 _ T p 4f.K_L^!,P_F  xPfcBjMf  P T , 

originate  g_pf  oi.i i mf  ‘T’  t : 

TLS.OPSPw^St'-jSCCT  T yf  rn  "t  *1  _RF  TS. 

iMPyf  f-F  NTS ! 

VMS  I ON;  TL3_HPSP’P' . 
iAiCOFPORATt  S J 

OP  IGINAT  IM;;_MF_,}UIRtP  F m : 

T l.  3— [>P  S PR  — f*  A } AGP  APh_  w_  | _A_F'J  >>r.  T I O'  41  _Pf  fjP  I KF.  "F  k Ts 

OP  IGINA7  JPG,  <t  311Rf:”f7t" 

T I S<-nPSPP'_PA  RAGf<  APh_  S_?_  1 _4_FUMC  T T Al  _pf  f,i  TPFr  t M T S 
TRACTS  t7i. 

1 Ml  I T_  I N TrB’F  A F F ! Ct_Tf 
-1 1 1 T F l.iT_  7 N T i FACT;  t”_fi  T 
P_JTT;  CC_p  F 3P  "*NSe 
SI'^SYSTf'!*"  3 SC P , 
pncup  t f t r r>  bys 

So jpct : tls.j'ipsm__x i_tpack_l.oop_[  xffp im{  m , 
jNCnpPf*-»ATFf>  I'.; 

’P  I G I N A T J n G_  R E Q I ' I P p ► FA  7 : 

TL  S.T'OSPP^SP  C T I 0 ' _ t_?_ri  f.CT  l ONAI  _P-f  G'lJTBF  a F.MS. 

0 F 1 G I N fl  T I P G— R f G l 1 1 P L ' L r’  T : 

Tl  S^OP5pH.SiHShC  T I V '_t!LF  P o w p a p C T _ R F G u I K M F N T s , 

I MpyF  ^F'  'ITS: 

VF  RSI  IIP:;  TI.S_i>PSPR, 
orrijf  tr.Tf:u  F,  y • 

SO  iwrt  : TyS_  H>SFR_*  1 _ T R a (’■  K_  L f*  3 P_  f Xf  t « I P f M . 

IMF  f’F  POP  A TFI  I'.; 

f,FIGI\A  TJ-.G..RP  ‘Jl'JPt  1 ppt: 

n o^np'jrp^sFcT  ir»\_i_2_plr>f  "RfA  •■cf.pi  iJ1  * I p L ‘it  n t s * 

OR  1 GIN  AT  J A G_Rf  G1 1 1 Rf  'F  P T S 

Tl  S„UPSpW_Sl  -3 3 F f T I i_?,2_F  yl  F T [ 0 f Al._PF  .31 1 T <■  t F E T S , 

I',pLl  -^F  us: 

VFBSIOT.  : TL3_FF'SP'P  . 
iAiCfiPPORATFS: 

op  IG  I fJ  A T I IjG_RP  .311  I PF'  t p T : 

Tl  3,J)PSPF..P  AR  AG»  ApH_  ^_?_<?_A_FnMr  T I "‘'AI.^F'T  IJI  IPF.l'T  NTs 
OF  IG  I PA  T r.r;_  3F  ;i  I A'F~tT 

Tl  S_nPSPP_PABAQR  APy.  IMCT  TOML^Rf  GL  I REGENTS 

ORIGIN  AT  J RF  '31'  I R £ F F~  T~ 

M S^PPSPR^PAR  AfJP  APH„  i_?_c'_C_FU  JrT  I n P A I _P'[  Ijy  I h £ F't  NT  S 
OFIGIMAT  I •)G«*P  .3 1 ’ I P t T F ” tT 

Tl  S_r  PSP*_P  A pa  GP  4Ph.  i_?_?_D_Fil'Jr  T I OP  Al.^Rf  GiijPFf-fc  Ms 
o F I G 1 1 J A r I -G.BF  jI  1 1 13 1 p F~t” 

Tl  S_f  PSPR^P  AR  AGP  APh_  _F  l.nr  T T Of.  Al.^Rf  UblRF-'  E A Ts 

TRACI S TO; 

Oi'TPiji^iMtRF  ACF  ; PArAR_l'lJT 
W_  JF  T Rf’SpoNST_Tn—  RAT’AfT 
r.mft;  skm^i? 

R^'Jpt:  x " i , 
npctjf  tMFo  f* v ; 

Sf  iwcF : tls_''pspp_x  i_  tp  aCk^loot^f  xft.  »if'LP  t , 

J AiC  opporatt  r l ’J  J 
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ORIGINAT  I i G—R £ 13UI«EV^  NT  : 

TL3.RPSPR.SE  C T I 3„  ?_,f-  l;NC  T I AM  A!  .REGHTREl  tf  TS, 


ORIGINAT  jNG.Rt.QUI  REHEAT; 

TIS.DPSPR.SUciSf  CT  I nN_5_2J?-PE,RMRi'ANCE.REf)UlPF  mF.NTs, 
ImPLE^FNTSi 

VERSION;  TLS.DPSPr, 

POCURENTFp  C-Yj 

SOURCE:  TCS^OpSPR^X  1 TRaT.K.LO^P.E  XPtR’IMFNT  , 

INCORPORATED  IN; 

ORIGINAT I NG, WE QUIRt RE M » 

Tt  S.DPSPP.SE CT  I ON.  3.  ?_  P E E E fl  w n A N C E .R  t Q • 1 1 R E I'tM  S. 
ORIGINAT  ING.RF GUI  RE F'LM  : 

TLS.DPSPR„SI^SECTIiTN_3-.2-,3<_F|jRCT  I Pi  AL_HF'3l)IRE'-'fcNTS, 

Implements: 

VERSION;  TLS.OPSPw. 

INCORPORATES: 

ORIGINAT  I Ni,_»EQL' I RF>  F NT  ! 

Tl.  S.llPSPR.P  AR  A(JW  aPh„  3_?_3_A_FHNC  T ION  Al._RE  QI  IREt'ENTs 
OR  I G I N A T I 'T R t (3 1 1 1 P E 1 F ” T~ 

r L S.DPSPR.PARAGKAPh. 3_?_3_H_EU  If  T TONAL.Rf GLIkEME  NTs 
OP  I r,  I IJA  T I NG.RC  'JI.'IRfcNF  ~t7 

TL  S_OP5PR„PARAf,p  apH„3_?_3_C_FHNC  TI  onaL^RI  Qb T RENE  M S 
Ok  I G I N A T I NG— wFiJU  1P£F  F N t7 

Tl  S_DPSPK_PAPAGR  aPh.  3 ?.3.D_FU'ir  T I uNAL.Ef  Q u I K E rt ENTs 
ORIGINAT  ING.RE  )1'I»e"em"I 

TL  S.pPSPR.R  APAG«APH_3_?_3_F_FlINr  T T ONAL.Rf  GUI  RENE  NT  s 
OR  I G I N A T I MC-_RE,3U  I R£l  F N t” 

TL3_DPSPR„paRAgR4Ph_ 3_?_  3.E.F  UNC T I ONAL.Rf GU IRENE  NTs 
OP  IGINATI  'JG.PCQU  I W£NE  N tT 

ri  S.PPSPR.PARAgRAPh.3  ?.3.G.FUNr  TTONAL.Rf  UU  IRENE  NTs  , 
TPACF  S TO; 

En  T T T Y.CL  ASS ! I^AGL 
fcN  T I T Y— TYf,E  : IMAGE.IN  Track 
I l piit_InTLRF  ACF  s RAPa“_IN 
RFSSAGt:  T I.T  <>_COmn  AM)*" 

MF  3S A GF  ; T 1_T<?_RE  TLRi, 

■“ESSAGF.  1 T 3_C  TM.-'A;,;I 
MESSAGE:  T '.RETURN 

01.' TP|JT_I nTE.RE ACF  : RapaR_out 
R_.NET  : RFSpONSF_T(*-,R  AT  a” 

R..NET:  SKtO^R 
R.  3E  T : X m I T.R  , 

DOClJME n TED  RY; 

SolIrcf  : tls.opspr.x  i.tkaCk.lo.op.e  yPERP  tNi , 

IN CORPORA  TEC  IN; 

OP  IGINATI’  G..RF..GIJIREE  ENT  : 

Tl  S.OP  SPk.SE  CT  I0v_3_?_ri  nC  T I ON  Al.R’E.QU  F RE  RENTS, 
ORIGINAT If  G.RE GUI  RECENT: 

TLS„OPSPR.Sl'3SECT  ION_3.2_3_Pt RE or'RanCE.RE OUTRE  "ENTs. 

I n P l I RF  RTS : 

VERSION;  TL'j.iiPSPR, 

COCURENTEn  PY; 

source  : tls.opspr.x  i.tr ArK_LOop_EXPtR'i*F t,T  • 
incorporated  in; 

ORIGINAT  lNG.REi3UlRtf,E  NT  J 
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T l S_QPSPW_SF  CT  I('S-3_f'>_PrpF  OKI-'A 'iCE.Pf  r j 1 1 1 w f-  m p nTS, 

OPir, inat  ja  g_RFQ|'Im£*lnT  : 

US.DPSPR„Sl'dSECTIO,4_J-<?_u^P|Jf'CT  ini.Al._WE  }i 1 1 K E “E “-T  S , 
tMPLFMf NTSl 

VFRSION,  TIS«..’PSPR, 

I.SiCnpPfWATF.Ss 

n p I G I Ki  a t I r._  w E J i 1 1 w £ f F.  n T : 

Ft  3_DPSPP_P  4RAGWAPH_}_?_U_A_FIJNr  TT  f"  Al_«E  (JL  I^E'-f  E T5 
f?p  I n I f4A  T I NG_«t Q»-'  I «E f'E~ T S 

T l S_nPSPW-PAWAc,w  aPh_5_?_«_B_FU-'JCT  I «naL_RE  OOlREf  t fT$, 
traces  r”: 

W_NFT;  C^NTl?nL_Kfc  SMIRTES 
K'_NF  T ; «.MjAH_shm,,ary 
subnet;  si.r*_RE  turns 
signet:  T A L L y— WE  T (jE  f'S  , 

Dt3C UT' fe ^ TEE  «v: 

SO  IRCE  5 TlS_PpSPW_>  1_TRaCK_LOOP_EXPE.RI"F  NT  , 

Incorporate!'  in: 

nwir.iMAT  ifii,_wE  )UlpEf  F KT  : 

T l S_l)PbPP_SfcCT  I **N_3_  P_F»  ■NCTT(J'«AL_WE.OUlRtf  ENTS. 

OP  IRINA  Tir.  G_pE  giiTPE"'Ev‘T  s 

T L S„0 P S p W_ 3 1 1 3 S L C T I on_  W_«_PeF  F f»RR  a F _«e:OIJ I R£>F  N T 5 . 

I*PLE  *F  4 T s : 

VERSI"f  ! TL3„OPSpR. 
pnCijr  fcf.TEP  p 1 1 

SOURCES  TLS_r,,PSpW_X  1_T«  ACK_Lr,Tp_F  XpERI*-!f  fJT  , 
INCORPORATED  I N j 

flRIRINAT  !NR„pK  U!I«Ef  E.NT: 

U S_DpSpR_SF c T I n N_3_ ?^PF  »F ,1RM  A MCE„PF  Ql 1 1 S E ME  N T S , 

Op  I R I N A T IE' G_PE  IJU I pt  f'F  ■ T ! 

TLS»0pSPM.Sli3SFCTin  - _3_^_e-.ruf  C T I nr  al.ME  3i  i IRE  MEf‘TS , 

IMPLE  MF  4 T s * 

VERSION:  TI.S„PPSpR, 

incorporates s 

HRIRInaT I "G.Rf  tj ipepf nt  j 

T L S_npSpH'_PARAGpAPH_  3_?_s_A_FU'if  T I fiNAL_KE  Ob  I REGENTS 
CJW  I G I N A T i“g_WE  Jl  1Re"e”t7 

1 1 S.npSPw_PAWAGpApH„  i_p.N_3.F"  4CTI  n'UI  _pE  D b I K E P F N T 5 

<?RlGr4ATINr»„«E',Jl'lHtT  ENT  S 

U 3_PpSpw_pARAGF  APh_3_?_^_C_FHMCTT  n\'AL_pE  Mb  I REGENTS 
C1RIGIMA  Ti7g_REC31!I  pe”ek  t7 

T i S_pPSPW_PAWAGWAPH_3_?_5_0-.FlJgr  T jnNJAl_RE  GOIKE*EMs, 

TRACES  roj 

on  tpijt_  inTerF aCF  : I ata_pEcorp 
R_NET«~  CC_RKSPnN.SE 
w”me  t : pa”aw_s')^^aR  V 

R~4FTt  RF_$P  1NSE_Tft_RAf>  Aw 
SUiSYSTF-U  ;jSPFRMFl, 

DOCUMENTED  P V ; 

Srt  .IRCE  J TlS_1)PSPW_>  1_TR  ACK_L  «OP_E  XPERI^E  NT  . 
INCORPORATED  1 i; 

ORIGIN  ATI  NG.REfJ1 ' [Regents 

T1  S_pPSPR_S*'  C F I ON_3_?  FlifjCT  I ON  A l _REOU T RFNEN TS , 


ORIGIN  AT  if  G_«EOUIRE'vENT  : 
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TlS-.OPSPK_Sl'rtsiCT  T 0'_i..O..plp  * or* ahCE.RUguI Rp  *EnT&, 

Implf^e nts: 

version:  tls_dpspr. 

documented  »' v s 

SOURCE:  TLS.OPSPR  X]  TRaCK.LOOP^FXPePIME NT, 

INCORPORATED  I*.J 

ORIGINA1  ING.PE  U'I»E('fcNT  : 

TL  3— BPSPR.SEC  T I '“N.3.  ?_Pf-  k'F  OPMA-TE.PF  G"  I RE.  f'E N T S , 
OPiGINATiNG.Rt  QUlBErt  Nj  : 

TLS.WADAP.DrS.lT  S_PAPagPaPh_3_?_';_fi|NCT  I aI  .PEGU  I PE:  F.NTS, 

I M P L T Pf  'US: 

version:  tls.dpspr, 

TRACFS  T 0 : 

f J A T A : RADAR.ClOCN.T  I N*  f , 

dbcumef ted  by  : 

SOURCE:  T L S.P A n 4 R_r  p s_ I N TE  RF  AC  F. SEE  C I F I C A T I 0 N , 

OPIGInaT  If  G.PEOUlWE'-'fcNT: 

TLS„RADAR.l)PS_IFS.P  APAGP  aPh_3.?_R_PE  RFO»>’ANLE-RF  0U1«E  "ENTS  , 

IMPLf  mf  NTS: 

VERSION:  TLS.DPSPR, 

documented  fiV: 

SO.IPCE. : TlS.PADAB^I  PS_lNTtREACF_SPEC  tfic  at  ion, 

OUTPUT.tNTfe'PFACF:  CC.’Uf, 

CONNECTS  TO: 

subsystem:  SSC2. 

PASSES: 

message:  : aC<  '“••-i.eKei'fM. 

T r A c F 0 From; 

0 P I G I N A T I N G.  W £ iJ  U I R E r ENT: 

T l 3-DPSp».PAR4GRaPh<_S_?_>i_>a_FU'IC  T T o»  aI_RE GU I REUfc N Ts 
OP  IG  I ri  A T I N’G.RE  JD  I Re  ’'t  N tT 

TLS_NPSPk_Sl,r<SECTI«f'_3  ?.  1 .F'UNC  T I o N Al.RENU I R t MU N T S , 

refepre  o“by : 

R.'JfT:  (;f_Rf  Sm.jSE . 

OUTPUT. I NT EPF  ace:  Da T a.REC OrC . 

C0NNFCT5  TO: 

Sl'rtSYSTF*;  SSOFk'irL, 

passf  s: 

Mf SSAGE  : radar^uSaGF 
Of  SSAC.F  : STATE.UPpATF 
M F S S A C» F : TRACK.INjTlATTfN 
m F S S a G t : tr\C*.TFrf  Ration, 

TRACED  FRO"; 

OP  I G I N A T I NG.REDU I P u f ENTS 

U S.r)PSPR.SU*:SECT  MN_?_e_S_FUNC  TI0NA  l.PF  MU  1 RE  HUNTS, 

P E F E P P t J**  R Y : 

P.  JET;  CE.RESponSE 
W.NET:  R A f'  A W.SUH'M  A*"  Y 

R.JET:  wF  Sp1NSE.Tri.  RAriAR, 

OUTPUT.  I MTE'RF  ACF  : PAD  A R. 0|JT, 

Dt  ScMFMon: 

"THE  W/VUOHT  INTERFACE  PROVIDES  ThF  MECHANISM  THROUGH 
WHICH  IMF  DPS  TsSUFS  compands  To  T*E  E’ALAR  SUBSYSTEM, 
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ThF  RADAR  SUBSYsTFm  "ILL  E X E C * T fc.  OU^Y  THE  C^PAnDS 
ISSUED  b*  IMF.  DPS  AM'  "II  L TRANSMIT  Of.E  PULSE  FqR  EACh 
command  " h i c h satisfies  thf.  p a r a p subsystem  and 
INTERFACE  Constraints,  T^t  RAPAP  SUBSYSTEM  "ILL  EXECUTE 
The  cnM'  i iDS  IN  The  or['ep  RECEIVED  A^l  *■  ILL  FEGIN 
EXECUTION  AFTER  FFCFIPT  OF  END.oF.Tr  AT  S' I SS I ON . " . 
ENTEPEr.HY:  "H.  A.MtLTflN,  APP,  30,  1r:>7b,'-.~ 

CONNECTS  TOJ 

subsystem  sswacar, 

IMPLEMENTS: 

VFRSIONif  0RIGINAL_FI)H|  I C 6 T I ft  N.P  4 T F 0.  AijGUS  T _ 1 9 75  , 

passes: 

MESSAGE:  I i_T2.COmn ant 

*E 3S AGF  : tS.CTMmAnT, 

t w a c F D From: 

ORIGIUAT lNG_REJUI«Ef ENT ; 

TLS_DPSP«.PARAGRAPh. 3_?_1_A_FUUr T I0'  AL_RE  QbIKFNFNTs 

OR  I G I N AT  I UG„ REfJU  I Wfc'l  FNtT 

TL  S.pPSPP.SECT I r '*«3_?„FI  nCTIONAL.pF  GuT REPENTS 

ORIGIN  at  I •vG.RE-'JUIMfcr  f”t  : 

TLS_DPSPW_SUbSEC  T I Of _3.2_2.FUNC  T ] on  al.WEGU I R t MEN  T $ 

ORIGI.iATIUG.PEUUIREf  ELT  :~ 

T l S_DPSPR.su  TSEC  T Tof  .3.2. 3.F  U^CT  I ON  A l.RE'LU  I RE  Mfc  N T S . 

referre 3”ry : 

R.VET:  X u J t_r , 


PE  RF  ORmAn C t.BFnulRGMEJT  : ENERGY  Pe°_ImAGF. 

test: 

"CONS  I 

E nF  RG  Y_l  I M I T sb « :l  i ( * T e f P p R A p V REPLACEMENT  FpR  (TBL),  *) 

V ar 

IuaGF.ENEPGY;  Real; 

BEGIN 

EnF  pg y_per_image : = true ; 

PETWTEYE  F 7 R S T RECORDING  Ff’P  START!  NG.P  0 I N T ; 

FeF  F AC.H  f I m A GE.H’A  NO  0 V F R PECORDING 

no 

I m AGE.ELF.RG  Y t s'’ , 0 ; 

FOP  F AC  P PADAR_COMMAN,)_M  TPUT.POIUT  REC0R(InG 

SJCm  that  (i?  ad  ar.ct  m7  a np.oii  tput.po  I NT  , T APGF  T_IC  S 
C2_lMAGE_HANrOVF  R.’tf*”lD) 
ro 

SELECT  first  RECOpr  FROM  starting.potnt, waveform. table 

SUCH  THAT  (RADAR.  C 0 m m a m p_  0 1 1 T P U I „P  0 I N T , R A D A R_  TYPE5 
S T A P f I N'G.P  "TNT,  w'F.N  A ME  ) I 
IF  P F C opO.F OUNO  The” 

I maGE. ENERGY := Image .ENERGY* 

STaRTInG.PTTM.nf.CRARACTEKISTiCSI 

f v/PForf  ach; 

IF  ( tmagf.fhf  rGy>enefgy_i.  I'M  t ) them 
EuFR(,v“pep_,Iuagf  • s f a”sf  j 
emforeach 

ENul  ”, 

CONSTRAINS: 

VALID  AT  I0t'.p  TTH:  C P A Np  0 VF.  R.C  OMM  A N'l>.  I NF  DT 
VALIOATT  fli\”P  A I H : RADAR.fOMk  AMO.  OUTPUT 
VALID  ATTO  '.”p  A T H | RADAR.wAVrFORM.PROPFRT  IES, 

TR A C F 0 From: 
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D f c T S I M : •?AOAB_R£S,H|Kr.F_C*NTRftl_M 

T R I G I N A T I*  f,.PEigiJlRF.f  F.  f.T  : 

II  3_pr>SPR_nAw  AGRAPH„3_?..<J_B..PFRF«RHAiir  E.I-Ei.i:1#1  ► tMS , 

PCRFORMANCt'.PtQMlKfcHE-wTS  P I U.  5 E S Pfc  «_SE  C TRD  , 

TEST: 

"CCNST 

PULSt^W  A TE_L  IMlTs2n,0J  (♦  tF^phRaMY  RF  Pi  ACfME  !• 1 F«r  (TpD),  *) 
VAR 

PULSE.RATtl  IMEGER I 
INTfRVALl  REAL; 

BEGIN 

pul  se  s„pek_sf  c'Jnujs  true  ; 

r o P EACH  R~l)Ap-CfHHAND.f'U'TpUT_PnT -JT  RECORDING 

C p 

PUL  Serrate  : = r,» 

INTERVAL  :=BAnAR-Cf’MMA\r-^uTPUT-Pf*If'I  . M?ANSE'IT<_Sl  ART; 
f ic  Each  w tput_P"tnt  ctcnwrUG 

SUCH  That  ( CRAdAr^cPeTmm-^iiTR  'T_PMi-I  ,T|<ANS'-'1  T„STaRT<5 
I • ! I E fi  V A l ♦ 1 , 1 ”mP 

(f?A,-)A»_cf”'*A\n_'JI.''TP  '^E’MnT  ,TE  a i>  SI  I1_STaPT>s 
INTERVAL)) 

ro 

PULSF.RA  TE;jsPjL5E_Rate  *15 
E Nf FARE ach; 

IF  f pUL5F_R A IE  >PUl  SE«  R A 1 F _L I ^ 1 T ) THE* 

PUI  SES-PER-oECr,NO  jse  At  5? i 
ENT  F pre;  ath” 

EM)J 

Cpn strains  : 

V AL  IP  a T I A T H ! R AO  AR_C  AMP^IV  '1  Pl.lT  , 

TRACI  0 FRftMj 

PP  I G I N A T I f r;— RE  'H1 1 Rfcl  f NT  s 

T | S_nPSPR_PARA(;R  aPh^3_P_  0_H_PF  RF  "E  */.nr£_E  E i.UlRtf  ENTS  , 

PE  RF  PBH  ANf  E_RFf!UI  Rp'F  NT  j R A [)  1 A T F P J'f'»  E.P  . 

TEST  : 

" C r'  N S I 

R AIM  4TErj_P(**t  R_L  I'1 1 T=G.  O ; (*  Tt*'P'*RAPV  REpLA(EeE>T  EOR  ( TflD ) *) 

VAr 

eia(>ar_p<v.fr  : rl4l; 
interval:  pfal; 

BEGIN 

madia ted_p**e R : = t rue : 

Rt  TM  T Evt~F  T wST  R E. C-  A M P I T G P ” R S T AR  U GG_P  ft  I u T ( 

FflP  EACH  E APAE-C'1‘jyANf)_HiTP|lT_P(1I*)T  R E.  F P R f)  1 1 G 
Dp 

CAPAR^PP^ER'JS  ' , > I 

INTERVAL  JSRAP  AR^COMMAUi-i^PtiTPIIT.E’PINT,  T»ANSm1  T_S  f ART; 

FTP  F.ACH  RA|)AP-Cf,E,,1ATvD_~E  TPUT_P*IfjT  PtCftRtl'G 

SUCH  That  ( (R  ah ar_C  pm»* am^putpu^pp  i M ,TR  an&mIT^St  ART<s 
InTERvA)  ♦ ) .(>)"*ANr> 

(R' APAR^CPMk'AND^PlJTPDT^PP  I^T.  TRaNSh1T_$TART>s 
INTERVAL)) 

r e 

SELECT  FIRST  RFC"Rr  FRPf>  ST  AM  T I NG_P  P \ nT  , R a VEF  CP  P.T  ABLE 
SUCH  THAT  ( R A P A R_  C P t * *'  A N 0 _ 0 i ' T EM ' T _ F m T N T , R A 0 A R _ T Y P t = 
STARTING  Pp InT , «F_NAMf  ) J 
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IF  REC',Pr?,F  *Li\D  T np  ij 

fv  al>  ar.PO  -gfw  » jK  at  a p_p  a ke  « ♦ 

stapt“^g„p^Ikt ,wr_t:H*h  acteristIcs; 

FNPFrtRtACM; 

IF  CW4l)AW_P'i*t"W>PAr>IATEr'->P(*KFR_LI'''TT  ) ThEF 

PAnrATEu.P'.vFSfsFAlSf;" 

E NT  F.MF  AO 

e.nu;”, 

CONSTRAINS; 

VALIDATlC?''_PATr<:  p AHAP^r.  PHH  AfJO^rM'TPUT 

VALIPATKV'v'PATri:  RADA  p”  K A V f F * PH  P R r> pF  « T I E_  S , 

TRACED  FROmj 

DECISIS;  PADAR_RFSniPCE  .CfNTRnL.HP 
PRIG  I MAT  ING..RE  JUIRe^  EM  : 

ri3..DPSPR_PAPAGRAPH-  3_  P— PE  PF  HPh  ANCE—F  E i.UI  RE  F t N y S » 

R.NFTj  CC.FESPPf'.SE, 
refers  t^{ 


al  pha  : 

AC  KM  Th  lF  G(>£ 

a i pha : 

CC— ERP  TW_PRF  CE R S I M G 

AL  PHA  : 

ENGAGEMENT  ImtIaTIHm 

al  pha  : 

S T Aw  TE  P 

alpha  : 

T F R''— E.  MG  a Cf  h p;  k t 

ALPHAS 

TER^TRACK 

Al  P H A ! 

TR  ACK_I N I T I A TF 

ai  pha  j 

v al  I o a te_h£  Anp-p 

DATA; 

C iiM<  Ai'lO—I  C 

DATA; 

p .'Hi Mr.' 

data. 

Hfj^lD 

d a r A ! 

IMAGE  ..ID 

EF  T 1 T 

CLASS;  I PAGE 

EVENT  ! 

ALLOCATE 

EvE'-T  ! 

SCHEDULE 

EVENT  t 

S'JF’  -ARIZE 

IK’PlJT.I 

k T F R F A C E 1 c c _ T f . 

flt'TPl.lT. 

interface;  CC_«l  t 

fill  TP |J T— 

INTERFACE  ; L a"t/_rF. C^RD 

sihnltT 

RtC^RD_DPf*f 

V A L I P A T I r>  ,,__P  A I M T ! C 2_  T f A GE_  H A NP f>  V E P 

V AL  ID  AT  T,im”piImT  ! START  jMGlpPItiT  . 

EnablET  Ry; 

IF'Pmt.I 

f.TF.h’FACEI  CC_Tf  . 

TRACED  F«i»mj 

OP IG IN AT  p.G.PEtJUIRtl  F N T ; 

Tl  S^DPSPR^F  AR4GRAPN_3_i>_  l.A.FU'if  T T <V  Al_Rf.Gl.  IKEUf  FiTs 

ORlGIfUTIMG.RF.GUIRtl  e”t” 

Tl.  S_DPSRR_R  ar  AQR  ap»h_  3_?_«?..E_FlJMr  TIfH  AL_«E  Glj  I REF  E N Ts 

ORIGINATE  N'G— RE-lH*  I Pf  F F K t” 

TLS.OPSPR.PAPAGWAPh.  3_p_S_A_FUMr  Tl  pf.AI._RE  GulhEFENTs 
IF  IGINAT  IMf^REQHIRfF  F m“ 

TL  S.DPSPR.P  A ) A GRAPH.  3_?„S.H_FIHCTTi'naL_PE  Qb  I REMfc  NT  s 
■PRIG  I MAT  I 'lG.RE;rjUIRtP  p7!  T ; 

TLS^DPSPR.S'JHSEC  T lHK_3_2_l_EUMCTT''NAi._RErt'IRE*tF  TS 
PRlGIMATl"G«.RtUUIREf  "f  T !~ 

Tl  S.nPSPR.SlI-TSECT  IFF.^3  l S_F  UMC  T I PM  Ai__Rf.'l- Li  I PE  k't  F T S , 
ST«Uf  tl'RF  • 

it  pht_intfpf ace : cc^i-i 

aiphaj  validate^ pt*pfp 

El-71 


ALPHAS  ACKNOWLEDGE 

* jtput_i’.terface s c r_ ^ t ' t 

AM) 

CONSIDER  OaTas  cfM^ANr:„IP 
IF"  (HAND',VF.M.IMAGE) 

Al  I »i|  TP  A C K— J f.  J T J A T F 

V AL  It'  AT  I V,J‘3  I^T  • rp^IPAGE.HAMnnv'tM 
EVF.NT:  ALLOCATE 

mjTPitTwI'JTF«FAcf  s PATA_HFCf)Wl' 

PR  ( I K T T T ATf, engage  Hf  ^T_HfinE  ) 

ALPHAS  STARTER 

valtoatI',*'_pt,Int  s st art ing_pp  in r 

alphas  E NG  4 GEM  NT  INITIATION 
E'VEMs  SCHEDULE 
EVENTS  S'MMAWjZt 
T F R M J N A T £ 

P -J  (TEWHlNA  TE_F  NGAt-E  he  NT_mPDE  ) 

ALPhas  T E W m_  f.  ^ l a r,  F n F N T 
TF  RhjnaT £ 

PR  (DR  RP— TRACK  ) 

SELF.CT  E p T I T y_CL  ass:  I h A G E S'XH  That  ( It1  AGE.lDsH^Io) 
IF  (ROUND) 

subnets  wf  cf'«n_[’F  pp 
ALPHA:  TfcRfi.TwXr.K 

Pl)TPUT— INTFrF  act  s [)  A T A_RF  r ORo 
p T H F w w I S E 

alphas  cc.E^Bnu^s’worESSTNG 
T F R 1 ’ I j A T E 

END 

PR  (Ct,HFSS AGE»tPwCR  ) 

AI.Fha;  CC_ERWflR_PR‘'cESSING 
TERMINATE 

{ nn 

E.  HD 
ENG, 


R.NE  T s Cf  NTRflL.PF  SMJPCES. 

DESCE IPTIPns 

"thf  tls_ops  shall  implement  the  repuifenents  specified 

IH  The  U P S p W f »EfEPFNrF  ?.?,  ASS"CtaTfC  u 1 T H HAnAGF.mFnT 
and  CONTROL  PF  T I S RESOURCES  AND  S'<aLL  PERFORM  thL 
FLJF'C  T I 'u-jS  h^RE  I N DFFTImFO  AM.)  D I AGW  A Mf'E  D Ir  THE  CftNTRES 
R_nET , 

the  dps  shall  ASSIGN  track  rates  AM  E Nfc RGY  alLOwaNCES 
TO  EACH  T ,v  A g f h a N D F D OVER  F R * r c1^  haND  AND  cflNTRPL 

ai -r.  shall  deIfrhInf  energy  bounds  and  track  rate 

FnVELHPES  Fnf-  FAf.H  HANDOVER  image  ki-ich  REGAINS  In 
track  STATUS,  Thf.  ENERGY  rPUM'S  A|  p TRALK  RaTE 
ENVELOPES  ShALI  RE  MAINTAINED  ^ I T h I f an  ACCUrACY 
and  resolutitn  tolerance  sI!fficifrt  to  met  the 
SPECIFIED  »Er*"IR'EMFNTS  FOR  ')[  T F RL  J N A T I ON  OF  TaRGFT 
INTERCEPT  Cef-DTTTpNS, 

THE  DPS  Shall  ASSESS  STATUS  *F  THE  TLS  RESOURCES  AND 
SitALl-  AlLACaU  TLS  RESOURCES  ln  fc  A C.  H H A T 0 V e P IMAg* 
BASED  On  RAijAW  SLRSYSTFm  PFRF  oRmANCF  CAFABTlITIES 
and  shall  Maintain  A GRACEFUL  DEGRAl aTIOK  PcSTURF 
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WHILE  UNDER  OVERLOAD  Cfl^riTiri'iS, 

THF  ops  Shall  C-FNfRaTE  TLS  Pf-S«t.l»cF'  UTILIZATION 
PROFILES  and  shall  Commit  these  data  to  permanent 

PILL  THROUGH  TF-F  [>  A 7 A RECORD  0"tP|.T  INTERFACE,", 

WtPtFS  T n : 

ALPHAS  ASSIGNJJATe 

alpha:  CREATE.STATF.FTU 
alpha:  l«f)P»L{iST 

alpha:  m a k p _ a l i.  f1  C a t i a n 

Lttitv„ty°e:  image. t n_tw ack 
En ti ty.typf : l<*stj-iilsF 
ENT1TY_type:  RETURNfn  PULSE 
subnet:  tally.«lTijpms7 

ENAHLtf'  «Y| 

EVENT:  allocate, 

TRACED  FROM: 

ORIGJNAT  j',D„PF.,jUIMt>‘  FNT  S 

T l S_OP$PR_F’AR  arRaPh_  <_?_7_D_FiihctI0>  aL_P’EUL  IREF’ENTs 
ITP  IGINATING.PEGHIRe  RF  NT  J 

T | S-DPSPR„RARAGRAPH„J_?_a.A„FUNr.T  I0NAL_Rf  Q t,  I R F.  u E M S 
PR  IGINAT  INf,^  REQUIRE  mEntT 

T | S.DPSPR.PAWAGR  aph„  3_?_y_9_FU'JCT  I PML_Rf.  GU  IRENE  Ms 
PRIGINATl“G.PFi3UIPEf  F kt” 

TL  S.DPSPR.ol-'HSEC  T I ?N_3_?_u_f-  LJNC  T I PM  AL_RF.(jU  IREMt  N T S , 
structure: 

Di* 

F IFi  FACH  F -IT  IT  Y_TTPF  : PETUR ■'•FO-Pi‘LSE 
07  SU'JMCT:  tall  Y_PL  TURNS  END 

AT  D 

FOR  EACH  E IT  IT  Y^tYPF  ; LPST_P|ILSE 
CO  ALPHA;  DRfip.LOST  ENn 

AT  0 

FOR  EACH  E'.'T  I TY.TYP’t  : IMAGF.T'J.TPaCK 
po  alphas  CRT  aTP_ST aTE_F T LF  END 

t:T  i> 

ALPHA;  H a k F — A L L 0 C A T I f;  T: 

FOR  EACW  LnTITY^TYPe J K aGE.In^tpack 
00  alpha;  aSSIGN_Ratf  tN<> 

Tf  Rm  Ina  TE 
END, 


R.NET:  RADAR_S'JT'maRY  , 

refers  to. 

alpha;  c o M P L t TE— SljRhapy 

DATA;  HOOF 

entity.type:  returt rr.PuLsr 

FVENT:  SMMfAKJZE 

OUTPUT..  I NTEPFACE:  f.ATA_RfcCORO 

subnet:  suM.Rt turns. 

Ena  HI  to  PY  : 

Event;  summarize, 

TracFD  From; 

ORIGINATING., REQUIREMENT  I 

TL  S_DPSPR.PARAGRAPh„  3_?_<i_A..FlJ  JC  T I ON  AL_Rf  OL  IRENE  Ms 
OF l”l NAT  I NG.Pf GO  I Rem F NT  S 

TL  S.OPSPR.PARAGRaPh. 3_?_S_0_FUUC T T ON Al_R|.GU IRENE N Ts 
ORIGIN  A T I N G_  R E (J  U I R E F F NT  5 


J 
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T | S.OPSPP.SUHSEC  UNCI  ional_RE  RL'lRtMtE  TS 

1RIGIMATT  Mr,_Wfc 'QUIPt^M.T  j” 

TL  S_DPSPW_5‘-'3SEC  f I 0f'.3_ir_ri_P  U^C  T I m al.RE  I.  U 1 R L Mfc  N T S , 
STKUC  Tl'*»fc| 

CONSIDER  DATA;  mode 
ia  (Engaged  i 

F'r  EACH  EnriTr_TVPt  j fftTU«s<ED_PnU^E 
po  SUGUtT:  SUt-UPF  TLPNS  fcNO 
alpha:  C f,’  m p l e t e_  5 c h h a f y 
F VFMT : SIIH-URUE 
ft  JTPUT_  INTERFACE  S Da  T A_Rf CORD 
ft  P (ST  AND5Y  ) 

TER^IMA  TE 

EDO 

END, 


R.NET:  W A U A T I H t NG  , 

DESCRIPTION'! 

"RAI)AR_T  I"  I -JG  MAINTAINS  a RECORD  nF  T Hp 

^Ar)Aw~CLftCK_TlMEi". 

Pt  F EPS  T ft  ; 

alpha.  ijppATF^RAOAP^n  or* 

I>  P|IT_lNTF(.F  ACE  5 RA~AR_f  l.ftCK^Ui, 

EMhi  Er  pyT 

IMPHT_IH  rrpF ACE : R A P A p_ c l ft  C K „ I H . 

STRUT.  T l ?FJ 

IFPiT_IvTFPFaCE:  RAi)AR_rLftCK„IN 

ALPHA?  DPPATF.PAUAP^ClftrR 
TF RUINATE 
ENL. 


R.NfT:  RF  SPftNSE_T^_R  Al)AR  , 

D t S (,  F IPTlftri: 

-THE  TLS_r.PS  Shall  I mPlEMEN T ThF  p E n u I R E m F N T S SPECIFIED 
TN  The  TLS.RADAR^ftps^iNTFRFACE.SPKC  if  IC.fcT  lfliv  ASSOCIATED 
WITH  PROCESSING  RADAR  SUPSVSTff  RESpONSfS  TO  COPLANDS, 
AMO  SHALL  p E r F ft  r V THE  FUNCTIONS  herein  DEFINED  aND 
diagrammed  in  thF  peSpRad  R_net. 

THF  DPS  SHALL  Ff  CF I VF  AMD  rRHCFSS  radar  MtSSAGES 
TRANSMITTED  FY  T *-  F TLS  RADAR  S"HSYS  IF  M AND  S^LL 
INTERROGATE  each  MESSAGE  FOR  ERRftRS  and  SHALL 
PROCESS  ALL  CFTFCTFD  MFSSAGE  EPROFS. 

THE  ops  Shall,  I'PftN  RECEIPT  OF  ERROR. FREE  RADaR 
messages,  detect  and  profess  keduf Dant.ifages, 

GM'TSI.  IHAGES/  AMD  l (JR.FLF  V A T I ftM—  I P AGES  , AND  SHALL 
UPDATE  ST  ATE.PAR  AmF  T*  PS  F"R  each  IHAGl TRACK, 

THF  np S Shall  TermIMTF  track  On  EACH  IHAUE”^hICH  Is 
DE  TE RM I nE U I ( RF  ElTHEW  A REDUNDANT  ftR  GHOST  I N AGE 
ft  R WHICH  IS  FftipiD  T ft  E XCF  E(  ThF  LftR.FLEVATIftN 
CONSTRAINTS  and  Shall  maintain  TRACK  ft N EACH  image 
r>ETERMlNFn  T t RE  RFaL. 

T 11  f DPS  shall  Construct  AND  m A In  T a I N (ESCRIPTlVE  DATA 
FILES  ftp  Each  tuaGF  ^HlrH  is  either  1‘AIMAIMEO  IN 
Track  OR  D R ft  F P f p fRftM  TWaC*  anD  SHALL  PERIODICALLY 
commit  THESE  MATA  T ft  PERMANENT  RECCt  DS  THROUGH  TH£ 

data  RECORDS  interface,". 


w 


IMPlE^Fntsi 

yFRSIBN:  Pf.'L^— CnMplUF  T MI  TAT  T«r  ^crt^'PE  ^SaT  X or  , 

REFERS  T n : 

AlPHAt  F^k'^'IPDATe 

A I.  P H A J GHPs7„OE  TERN  IKAT  I PN 

AIPma:  GBbST.TERUjMtiHn 

Ai.Phaj  L^-ELEVATifH^pF  tE  RM  in  at  I pu 

ALPhai  LBh.TERN  INa  t I on 

alpha  : RUDUN.ntTFrtf'  Ih.  ATI«N 

ALPHA;  RFPUH.  TERhjE  at 

alpha:  rfhE'^ER.Stpp 
alpha:  rr.e  ppiR— prccessj^g 
alpha:  UPpATE.ST ate 

DATA:  FptJND 

DATA;  GHPST.IbAGE 
DATA;  I mAGF.IL> 
data:  l nn^ELEVATtaF 

DATA:  PULSE .Ifi 

data:  piilsfItype 
data:  radar” Type 
oaTa:  pe  ou'i”  an  t.  t m a gf 
data:  RR.nRoER.in 

DATA;  TARGE T_in 
DATA;  VAl.ir^RETURi'J 
EH  n TY_CLA!>S  : ImagI 
t'-,TITV_CLAS.S:  PULSE 

ENTTTY.T  YP£  ! IMAGE..  TN.TRACK 
IHPI.IT_IMTF.RF  ACt:  HM1AW_IN 
'11'TPUT_IHTERFACE:  L at  a”  record 
SUBNET:  EX  TRACT.MpASlicFHENT 

SUBNET:  h i s s I ' J G_  p f f i 1 R n S 

SUBNET:  R E C B R ■)_  ()  R fl  P t 

ENAHLtr  BY: 

I R'  P IJ  T _ I n T F R F ACE  ! RADAR. IN, 

TRACED  FRft”: 

hr  tginat  i ng.rf.  qu  i recent  : 

TL  S.PPSPR.P  AR  A graph.  3 P.P.A.FU  1C  T I BN  At  _RT  QU  IRENE  NTs 
(1RIGINAT  i"g_REDIJIPl.I  ENt” 

T l S.DPSPR.PAPAGR  APh_3  ?_2_H_FlMr  T I tfN  a L.Rt  «U  I RE  HE  N T s 
ORlGINATILG.REDUlREf FNt’ 

a S.DPSPR.PAPAGRAPH.^p.^.C.FUNr  7 I »NAl  _RE  QUIRE  HE  NTs 
3PIGINAT  ING.REQIJIWeRFNt": 

ri  S.dpspr.paragR  aph_3  P.2.D.E UNC t l pnaL.REQUIREmEN  Ts 
PR IG I N A T i”g— RE  QU I Re* En  t” 

n 3.DPS*  t_PARAGRAPh_3_P_3_A_FUNCT  I hnaL.RE.GUIREhERTs 
PPIGINATING_»E-TU1  recent  : 

U S.OPSPR.P APAGR APh. 3 p_3_0_FUMC  T I PML.RE  G'U  IRENE  NT  S 
BRIGINAT ING.Pt  HURE^ENt” 

TL  S„.I)PSdR_PARAGRAPh_3  ?_  3_C_FUNC  t T P w aL.RE  QU  T FEME  N T s 
BRiGINATIUG.REDUlREf ENT” 

TL  S.DPSpk.R  \ <AGR  APM„3_?_3_F_F'.INCTl('.MAL._«Lt3UIRENEMs 
3RlGINATING..RE'3UIREf'FNT  : 

TL  S.nPSPP.PARAGRAPH..  3_P_5_H_FUNC  T I ^.N  AL.RE  GUI  REGENTS 
BPIGINAT  INf, .REQUIRE RENM 

TL  S.DPSPR.F'AR  AQRAPh.  5.?_G.C_FINCTT  ^ UAL. REQUIREMENTS 
TP  l” I N A 1 I jG.PEQUIRFPENt” 

Tl  S.DPSPR.SUBSECT I«k.3.?_?.FUNCTI Pnal.RF  QUIRE BENTS 
TPIGI'JAT  img.REQUIRe'Tnt 
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ri  S.DPSPw.S'HSEC  nr)f>_3_,?_5_FUNCT  t"NAL-PEf.  IJIRfcMtMS 
fJPlGINAT  IMG.  ?E(3UI«Ef  ENT  »” 

rio.DP SPIES' l iSECT  I ON^.3  l S.FUNC T I ON AL.RE GU I RE^tA TS  , 

STRUC  TiMF.  j 

IMPL'  r_INTRWFACE:  RApAP  fN 

SELECT  ENTI Ty.CLaSS:  PUL SE  SUCH  THAT  (PULSE.IDsKR.ORDER.Ip) 
IF  (FOUND) 

TF  (WAPAR.TYPEsPIJLSE.TVPE) 

D 0 

ALPHA:  REME.KBFW.STOP 

POP  f-ACH  E N t I T Y.c  L A S S I PULSE 

no  SUBNET  I h T sS  I NG.RF  TURN'S  E Np 
SELECT  ENTI  TY.n  ASS?  PULSE  SUCH  THAT 
(PULSE.IDsRR.0pnFR.IO) 

TERMINATE 

AfJP 

SUHMET:  ExtP ACT.hE ASUREMENT 

IF  ( V A L I D_R£  t I IRnT 

alpha:  ijF n a t f state 

uO 

ALPHA:  li"'_ELE  VATION.I'ETeRKIDAT  ion 

IF  (LOk.eiFvATION) 

SUrN F T ; RECORO.pROP 

alpha:  Lfl^-TFR~INATI On 

OUTPUT  INTERFACE:  DAT A.P  EC  OHD 
■■’TheRwISF."* 

TEwp  InaTf 
end 

A NO 

ALPHA;  r hRm.I.JPD  A TF 

output. intfreacej  data.recpRl 

A \L> 

EOR  Each  EnTITY_TYPE:  image. in. track 
SUCH  teat  (lMAGeIlDOTAHGfcT.Il,) 

DO  ALPHA;  red UN. determination  end 
select  FNT I TY^CLASs”  7 MARE  SUCH  7FaT 
UMAGe.IDsTaRGFT.ID) 

IF  ( R£(  IinDANT. IMAGE  ) 

SURF  FT;  RECORD.DPOP 
ALPHA;  PEDUN.TFRMIUATION 
OUJEUT  InTERFACF:  DaTa.PEC.ORD 
OTHERwJ  sf” 

TERMINATE 

End 

END 

otherwise 

alpha:  ghost. determination 
if  (GHOST. tmagf  ) 

subnet:  rf  c ord.drdp 

ALpHA;  G H 0 S T. T E R M I N A T ION 
OUTPUT. INTERFACE  J DATA.RECORD 
OTHERWISE 
TERMINATE 

END 

f NO 

E'.f 

oThe&/.ise 

ALPHA : ww_FRRof._Pc-cESSING 


TERMINATE 


1 

END 

OTHERWISE 

ALPHA!  RR.ERROR*pROCESsING 
TERMINATE 

END 

END. 


R*NET|  SHED*R, 

DESCRIPTION! 

"SKED.R  CONSTRUCTS  TmE  ORDERED  FILE  OF  DATA  FOR 
A FRAME.", 

refers  T 0 | 

ALPHA!  INITIALIZE_SKED_R 

alpha:  pic**candidates 

DATAj  LAST.PULSE 
DATAj  MODE 
DATAj  TETF 
DATAj  THACK^RATE 
ENTITY.TYPE!  IMAGe.IN_TrACK 
Eventi  XRB 

FILE*  CANDIDATE 
Subnets  fprm.fpame, 

ENABLED  BY! 

EVENT:  SCHEDULE, 

TRACED  FROM  j 

DECISION  j RAOAR_SCHEDI)LEP.PRIORITIZATION 

opiginating.require^enti 

TLS_DPSPR_PARAGRAPh.3_2.2_A.FUNCTI0NaL-REQUIREHENTs 
OPIGINATIM G*  REQUIREMENT  I 

TLS.DPSPR.PARAGRAPh. 3-?.2_B-FUNCTIPNAL^REQUIREHENTs 
ORIGINATING* REQUIREMENT" 

tls„dpspr_paragraph* 3_?*2*C.FUNCTI0NAL_REQUIREMENTs 
ORIGINATING*REQUIReMENT  I 

TLS_DPSPR.PARAGRAPh*3_2*2«D*FUNCTI0NAL„REQUIREMENTS 
ORIGINATING* REQUIREMENT! 

TLS.DPSPM.PARAGRAPh* 3_2*2_E*FUNC T IPNAL_ REQUIREMENTS 
ORIGINATING* REQUIREMENT! 

TL S_DPSPR*RARAGRAPh*3_ 2* 3«D*FUNCTI0NAL— REQUIREMENTS 
OPIGINATING.REQUIREMENTI 

TLS_DPSPR_PARAGRAPh* 3_2*3_E*FUNCTI0NAL_REQUIREMENT$ 
ORIGINATING* REQUIREMENT! 

Tl  S* DP SP R_ Sl'R SEC T I 0N_3_2_2* FUNCTIONAL* REQUIREMENTS 

originating.requirementi- 

TLS_DPSPR„SUBSECTIoN*3_2_3-.FUNCTIONAL*REQUIREMENTS, 

STRUCTUREj 

CONSIDER  DATAj  MODE 
IF  (ENGAGED) 

ALPHA!  INITI ALIZE-SKfD_R 

FOR  EACH  EnTITY*tYPEj  IMAGE*IN_TRACK  SUCH  THAT 
(L AST*PULSE ♦(!, O/tRac K*RATE)<TFOF) 

DO  ALPHAj  PICK* CANDIDATES  END 
FOR  EACH  FILE!  CANDIDATE  RECORD 
DO  SUBNET!  FOrn_FRAmF  END 
EVENT!  XRR 
TERMINATE 
OR  (STANDBY) 
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URNII.AU 


r 


R.NF  T 


Ef  0 
ENC, 


1 


! XMIT_R, 

DESCRIEUftN| 

"XMIT_P  RHILOS  A \f;  FpRwAROS  T 0 ThF  OUTFUT.INIERFaCE 
'RAUA»_OtJT  THE  COENAMOS  nr  T Hp  FRAME,", 

REFERS  T": 

ALPhaj  F0RM_Ti_T2 
alphas  form_T3 

alpha;  PICk„C?mmanI 
a l 13 h a S SELCCT.CONmANC 
DATA:  PADAP_TyPE 

DATA:  RECORD.FOUNp 

EVENTS  5CHEPULF. 

EVENTS  xkR 

nilTPUT_TNTERF  ACE  s PAQAP_f*UT 

VAL  IDA  T I ON_P  0 I NT  ; R A p a p”c  OmM  A :JP_  0 U T P l'  T_p  0 I N T , 

F.napi  ep  Ry ; 

events  xrh, 

TRACED  FRBMS 

DECISIONS  RAL)AR_SckFCHLFR.pPIl1RlT  IZATlftN 
DRIGINAT  INCJ.REJLil^E'  FNT  S 

TLS_PPSPR_PARAGRAPh.3_?_S„A-.FUNCTIPNaL_RE  OU1  REGENTS 
iTRIGINATING.REQUIRE'fEKTT 

TL  S_PPSPR_r ARAGRAPH_3_2_2_B_FUNrTIftNAL_RE  &U IRENE  NTs 

originating. requirement” 

TL  S_DPSPR_PAPAGRAPh_  3_2_2_C_F  (INC  T I ON  AL_RF«U  I RRNE  NT  S 
OPIGINAT ING.REQUI»f”fnt” 

TL  S_PP$PR_PARAgRAPh_ 3_?.2j).FUMrTlONAL_REQUIRENENTS 

opiginati”g_reuuire”f”t” 

TL  3_PPSPR_PARAGRAPh_3_?_2_E_FUNC  T I Of  AL.Rf  GOIREMFNTs 
OR  IGINAT  i“g_»F.QUIRe”ent7 

TLS_PPSPR_PARAGRAPh„3_?_3-0_FUNCT IONAL.RE Out  RENE  NTs 

OR  I G I N A T I N G_  R E Q IJ I P £ f F ” T S 

T l S_PPSPR_F  ARAGRAPH^3_2_3_E„FU'JCTinNAl  ..REQUIREMENTS 
OR IGINA T i”g„RE QUIRE RENT  S 

T | S.DPSPR.SUHSECTInf _3_2_2_njNC T I ON AL.RECU I REME M T S 
0 P I G I N A T I n G_  R E Q U I R E I"  Tn7  S ” 

TL  S.DPSPP.S'IRSECTToT  _3_2_3.FUNCTirNAL_REt.UIR6  MEMS, 

STRUT  TURF  s 

Al  PH  A | SELFC T_COMMAnL 
IF  (RFC  ORP_F  OUnD  ) 

ALPHA;  “pir.K.COHMANp 
EVENT;  Xk« 

CONS  I PER  data;  PAPAm.TVPE 
IF  ( T 3 ) 

ALPHAS  F0RN_T3 

OR  ( T 1 OR  T 2 ) 

ALPHAS  FORh_Ti_T? 

END 

VALIDATION. POINTS  RAnAp_COMMAND_OHTPUT_POlNT 

0 JTPtIT.INTERFAC  .5  PAPAr”(0UT 

ATHFRwise" 

FVENTs  SCHEDULE 
TERMINATE 
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END 

END, 


SOURCE  I T L S.DP SP R.X  l_ TR AC K.L^P.Ex PERCENT, 

documents: 

ORIRINATING.REQUIRE^ENTI 

TIS_DPSPR_PAWAgRAPh_3_?_1_A_FUNCTIONaL_RI  GUI  REGENTS 

or iginating_reoui recent  s 

TLS_DPSPR_P4RAGRaPh„  3_.2_.1_A_  PERFORMANCE..  REQUIREMENTS 
ORlGINATING_REQlJIREf' ENT  l 

TLS_DPSPR.PARAGRAPH.3_?_1_B_FU^CTIPNAL_REQUIREMENTS 
OFIGIMATING.REQIJIReEFNT  : 

Tl S_DPSPR_PARAGRAPh_ 3_2_1_B_PERF0RMAuCE_REUU1REMENTS 
ORIGINATING.REaUIPE^ ENT « 

TL  S_DPSPR_PARAgRAPh_ 3_?_2_A_FUNCTI0NAL_RE  GUI  REGENTS 
op  igi  nat  ing.requ  i Recent” 

tl  S_DPSPP_PARAG»APH_3_2_2_A_PERF0RMAhCE..PEWJlREMENTS 

op igi nat i"g.re gui Recent” 

TLS_DPSPP_PARAGPAPh_  3_  ?_2_tf_FUNC  TIf,,'lAL_Rfc  QUIRE^ENT  s 
ORIGINATING. RE QUIRE ment7 

1LS_('PSPR_PARAGRaPh^  3_  2_2_B_PERFPRmAnCF..FEUUIREMENtS 

opiginat i ng.requ I reme n t I 

TLS_DPSPR_F AR A graph. 3_ 2_2„C_FU.QC TIPMAL_ REQUIREMENTS 
ORIGINATING. REQUIREMENT! 

TLS_DPSPR_PAWAGRAPh_ 3_ 2_2_C_PFRFORmamCe_PEUUIREMENtS 
OR  IGIMATING_RF.QUIREf  ENt7 

TL  S_D?SPK'_PAR  AGR  APh_  3_  2_2»D_FUMf;  T IONaL.  REQUIREMENTS 

originating. requirement! 

TL  S_OPSPR_PARAGRAPh. 3_?_2_D.PF.RF0P"'AnCe.REGUIREMENtS 
ORIGINATING. RE QUIRE' ENt7 

Tl  S.PPSPP.PARAGP APh. 3_2.2_F.FUMC  TlOf aL_REUUIREMF.NTs 
OPIGINAT ING.REQUIRE' FNt7 

TLo.DPSPR.PAR AGRaPh.3_ 2.2.E.PF  RFORmanCe. REQUIREMENTS 
OP  IGINATING.REQI'IReMFNT  ! 

Tl  3_DPSPR_P  aRAGRAPh.  J_2_3_A.F'JNCT  IonaL.REGUIREMENTs 
OPIGINA T ING.REQU  IRE^ENT  ! 

riS_PPSPR_PARAGR aPh_3_2.3.A_PFRF  OPMANCE.REUUIRtMENTS 
ORIGINATING. REQUIREMENT! 

TlS_DPSPR_PARAgRAPh_3_2.3.B_FUNCT IONAL_R{ QUIREMFMTS 
ORIGINATING  REQUIREMENT! 

Tl.  S_PPSPW_P  ARAG«  APH_  i_?_3_B_PFRFrPMANCE_REGUlREMENTS 
ORIGINATING. requirement” 

TL  S_DPSPR_PaRAGRAPh_  3_2_3_C_FIHCTIPM  AL.Rf-  QUIRE  M»E  NTs 
ORIGINATING. REQUIREMENT” 

TL  S_DPSPR_M’  a?  a GRAPH.  3_  ?_  3.C.  PERFORMANCE.  REQUIREMENTS 
OR IGInat ING.REQUIRe^ T nt” 

Tl  S_nPSPR.PARAGRAPh.3_2_3_D.FUNr  T I ONAL_Rl  Gill  REGENTS 
«PlGINATl"(._REflUIRfcf  FNT” 

T | s_nPSPR.PAPAGRAPH_3_?.3.D_PF»FOR''ANCE.F  EQUIPMENTS 
-- IGJsati"g_RF QU I cE  m Ent” 

’ P Snw.P 4 R *GR a Ph. 3_2. 3_E_FUNC T tONAL.R*  QUIREMENTs 

* - I . I s*  t i *,r._REQH  IMEr  Ent  ! 

: A -»»  ,Rapm_  3_  2.  3_E_pERRORM4*iCE_  REQUIREMENTS 

t l‘  ,_p  Jl  I R E f N NT  I 

- * p-_  i_2.  i.F.Fi  <C  T IOMAL_RfGlIREr,ENTs 

•r  * • . -»*  «'  I **E  * f ” t7 

3.P.PF  R- *R''AnCe_REGU1RENENtS 


OPIGJMAT  Jng^PF.  GUI  PEE  EM: 

U s^opspr.pawagpaph.  3_?_3„g_func  t t r* * A i _«f  ut  i kf.ee nts 
gp  IGINAT  I Tl 1 1 E M : 

Tl  S_pPSRP_PAP  agPAPh..  3 ?_  i_G-.PE a ur  E— K f-  GUI  PE  Tt  MS 
APIGINAT  j”t.WEr)UIff£EENT” 

Tl  S-DPSPR-PA«A(;RAPh_  3_?_4_A_FII’iC  T I ft*’  AL_PHJUT  «E^t  N TS 
nFIGINATl~r,_PE'JUIPEf  Ent7 

Tl  S_C'PSPR_FARAGPaPh_3  ?_a_A_PFPF  rtF  H A NCE_P t UU 1 HE P t * T S 
OPIGINATi'g.PEQI'I^ET'ENt” 

Tl  S_PPSPR.PAPAR«APh_3  ^/j^B.FUUCTTnfvAl  PfQ DIF EKENTs 
ft  P T G I N A T I N G_  R E Q U I P E * E~t7 

T|.3_i)PSPR_PAPAGPAPH.3„?-/i_B_PF.PF''K>'ANCE„FEDUIWtFENTS 
gPlGINAT  i’g..REQI'!»E,,FNt7 

Tl  S_DPSPP-P4Par,R  APH_3_?_b_A_FU-Jr  TT  flf.Al^Rf  Q U I P F.  H E N T 5 
OPIGINAT  l"r,,«EQUIREr'E”T" 

Tl  S_l,'PSPP_PAR4r,KAPH..3<_?_S..A_PFRE  ftP*'  AnFE..PEGUlPtE'EMS 
OPIGINAT  i’g.WE  WIPf.E  E m7 

Tl  S_pPSPP_P4RAGRAPH_3_?_S_B_FUNr  T I A|._PE.GUIPEMENTS 
•IP IGINAT  i’g.PE^JIPetEKU 

T1.5J)PSPP.PARAGRAPh.1.3  ?_S_H..PF  WF  ft  Pm  A fjCE_F  E Dll  I PE T t N T S 
gpiGlNAT  i'g.pE'QH  1Pe~e“t” 

IlS^fJPSPP.P  APARPaPh.3  ?_b_C_FDDr  T M'Al  _PF  GDI  REGENTS 

ftp  I G I N A T I DG..PE DR  1 Re f E~t7 

Tl  S^DPSPR.P APAGPAPh.3  P.S.C.PERE  flP‘- AnCE.FEGUIPEE'EMS 

ftp  IG  I DAT  i"g.RE  aUIPfcl'ENT7 

Tl  S_nPSPR_PARAGR  APh_  * ?_5_n_FUNCTIft^Al  RE  GL  I PRE-E  N T s 
ftP  IGINAT  i“g_RE  3'jIRe”e”t7 

T | S— DP$PR— P4PAQRAPh_  3_  ?_  'S.G.PERF  ft  P’i  A nr  t„P  EG  1.1 1 Rt  PEN  T S 

origjnat  idg.pegi|ipe~e”t7 

Tl  S_DPSPR_SEC  t PN.3.0-F  I k C T I ft N Al.  — F’t  T'U  t Rf>  £ n T S 
CR IG I NATlNG.PEuuI RECENT t 

\ l 3_DpsPR_sr.c T i ft  i>_pe  rf  ftRM  a ir  e»wegd  i re  rents 
ftp IGINAT i“g_RKGUIPe~e”t  J 

Tl  S_DPSPR_SFC  T I ftN_3_  ) pi  r C T I ft  N A|  _Pe.  GU I RE  l EMS 

ftp  IGINAT  i“g.REUIIIRe“e"t  : 

Tl  S^PPSPR^SFC  r I ft'N-3_  1_PE  RFftRMA  lCt«.REG"lRE  F'LNT  S 
3F  IGINAT  i"g„PF.GDI»e"  E~  T : 

TLS^OPSPR^SEC  T I ft  !v_  3_  p F u,CTlflN'AL_«E  GUI  PET  ENTS 
9pIGImati”g„RE jni”t”f nt  : 

Tl  S_DP5PR_3r-C  T Iftri_>3_?  t'E  PF  PPM  A NC  t— PEUU  IPE  MENT  s 
ftP  I GIN  AT  i“g..pE«Di"e~FT  T : 

Tl  S^DPSPW.S'JVlSEC  T I M _3  2 1_F UNC T 1 ftN al_WF r..U  1 RE  Mt*  T S 
ftP IGINAT I N G^ P E 0 1 • I P t E ~T  T J ” 

Tl.  3—DpSE’P_SIJUSEC  T 1 gN  ■?  ? I^PtPFftPCATCF.REGL  IPET-ENTs 
CtP  IGINAT  ing.REG'JIPe.T  ENT  : 

Tl  S_0PSpp.S"^3ECT  Iftf  _3  ?_?_FUWC  T T « N AL.PEf.U  1 RE MtN  T S 
ftP IGINAT ING_*fcQUIRtl “m t” 

Tl  5_DP3pp_5,iBSeC  T TftT^3_)J_P-PERFftRPA"Cr_RE  UU I PE^E  E*  T s 
ftPIGINATi”G,REGUIPtEEN7 j“ 

Tl  S-DPSPP_S|l»vStC  Tl  P,E  _3_c_  3_FUNC.T  I ftuAi^PEGlIIRE  HE  NTS 
ftp  IGINAT  ing.REGUIPe'MnT:  ” 

Tl  S-inPSPP_SiJH3EC  T I nr  _3<_(>_3_PERFftPl'ANCE_RE  QU  JPE'-EMs 
ftR  IGINAT  ING.PE'QDIRe  TENT 

TL  S.PPSPR^SKBSEC  T I p f __  3 j^RJNC  T I ftN  AL^PE  OUjRfcMfcMS 
ftp  Iginat  i”g.RE  JDIPf.t?n7:“ 

T | S_r>PSFP_S|JHSECTIftr  _3  p_a_Pt'?FftRHANCF_PE  GDIRENENTs 
,PIGINATl“G.r,fcf)UIPEh  ENT 

TlS.OPSPP.SMHSECT  Iftf  _3  ?-S_FllNCTIftNAL_(WEGUlPtHtNTS 
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OPIGINATIU G— «E'3UIWE^ENT : 

U S.DF'SP^S'MSECT  Io»-_3.2..5_PERFo»han  Ct-Rf  QU IRENE  NTs, 
SOURCE:  TLS,RAOAR_DPS..InTERFACE  SPEC  I F I C A T 1 on , 


DOC JPENTSl 

ORIGIN AT  ING_RE  1U I »E^  FM  t 

TL.  S_RA(H«_1)RS«.IES.PAR  ahR  ApH„3_.^_9_FnMC.  T IPNAL_HLGUlREMENTs 
OPIGlNATlNG„RE')UIpEf  EN T : 


T l S_RADAR..DPS,.IFS_PARAr;RAPH..3_2_R_PFRF  ORMnCE_KEGUJREMENTS 


» 


SUBNt T s FXTRACT_MEASURE  RENT, 

IPPLE  mfnts: 

VERSION:  POL2— C 0“P  I L EP—L  T P I T A T I Pt;_C  f1MPENS  A T I ON* 

REFERS  Tflj 

At  PHA : SC  T— PULSE 

alpha:  T A SyR t P F N T — E X T H A f T 1 0 n 

alpha:  t3_pe asuREmF nt_E xTraction 

0 A T A j I n agE„  1 1) 

DATA}  TaRGFT_IO 
ENT  I T V_CL  ASS  s I f ‘ A g L 

fc'NTITY.r.LASS:  pulse 
enttty_tvpf.  : l^s^fulse 
E n T I T Y—T  YPfc : RETURREr  pulse 
Entity_type:  n_T2_py“sF 

EE  TIT Y_ TYPE  ! T3„PyLSE. 

REFERRFJ  by: 

R^RET:  RF.SPONSE_Tf»_PA|'AR, 

STRUT  TliRE  : 

SELFCT  F N TIT Y_ CLASS:  IpaGF  SUCH  THAT  (IMAGE.  Is  s T A k GE  T_  I D ) 

consider  e'-tity^clasS:  pulse 

If  CT3„PULSF) 

alpha:  t 3_  i E A S t.i  R E ^ F N T_  f x T R A C T I f>  N 

C1P  (T1-T2_PULSE) 

alpha  :“  T aslpe  mfnt^ex tract  pn 

OR  (LORT_PULoC  OR  PCTlRNpf:  PULSE) 

EM? 

alpha:  SF_T_PULSfc' 

R F TURN 
END, 


SUBNET:  fori.framf, 

OtScR IP  T ION ; "FTRm^pram^  provides  RadaR  CPNRLIC1  RESOLUTION,", 
REFERS  TO; 

alpha:  FU  l)_CONFL  I c T 

alpha:  n ake^c  ohm  Ayr 

alpha:  SET«LAST 

OA  r A : C A N|>  IDA  TF.—  I H A GF  _ I U 

DATA:  DR  OP— FL  A G 

DATAj  IMAGE.ID 

EN TIT Y_ TYPE : IUAGL„IN_TRACK. 

TRACED  FRO*} 

3RIGI  NAT  ING.RE  Ji'IRENENT  : 

TL  S.rPSPW.PARAGRAPH.  i_?_2_A_FUNCTI0»iAL_Rf  QU I REPENTS 
op IGINA  ting.REqUIweT  Ent  : 

TL  S_DP  SP  R— r A R A Gp  A P h—  3—  2«.  ?„H_F  UNf  T I ON aL^RE  GUI  REPENTS 
OR IGINATING.REGUIREPENT  l 

TLS_[>P3PR_P*R4GRAPh_3  ?_2.C„FHNCTITNa!._iKLGL  IWEMNTs 
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ORIGIMATrJG_rJEiJUIREf'EM: 

U S.t'PSPW.PARAGR  APh_  3_2.2.D.FU'kJCTT0MAL-WE  Gu I RELENTS 
'*Pir.IMATIlMG-WEtlUIREvENT  i 

TLS.DPSRR.PARAGRAPh.  3_?«.  3«»n_  F U •>.'  C TI'),-aL_REGUIREE  E N T 5 f 
referred  pvr 

r_net;  sked_R, 
struc tore : 

ALPHA;  F IMD^CCINEUICT 

IF  (NOT  PROP^HG) 

ALPHA;  MAKE.CC'^URD 

SELECT  ENTlTT^TYPtJ  I * aGE_  I N_TR  AO  SUCH  THAT 
(IwAGE„IOsCAHOIDAtE_ImAgE_ID) 
r*MUST“si'CrEEl)  SINCE  SELECTED  ntsi  CALLING  NET*) 
alpha;  SET.LAST 
OTHERWISE 
EG  0 

RE  TURN 
END, 


SUBNET;  HISSlNG.RfTURMS, 

REFERS  TO; 

alpha;  SET^L^ST 

DATA;  PfCEl ^F_STOp 
DATA;  STOP.TME 
ENTITv_CLASS:  FULsE 
ENTITY^TYPtl  LOST  PULSE 
E N T I T Y—  T Y P F. ; RE  turf  ED_PuLSF 

entity^ type  ; t1_T2_pu”se 

ENTITY^TYPEJ  T3.PULSE . 

TRACED  FROh; 

opIginating.REQUIPenfnt : 

H S-DPSPR_P*RAGRAPH_3_?_3_F_FUNCTIONAL_RtQUlREHENTst 
REFEPRFd”by; 

R_NETJ  RESpONSf.To„RAPAR, 

STRUCTURE; 

CONSIDER  E'lT  I T Y_CLASS  ; PijLSF 
IF  (T1_T2_PIJLSE) 

IF  TRECL  IVF._STOP<sTnp  T I *E  ) 

ALPHA!  SET.L^ST 
OTHERWISE 
FND 

CR  (T3.PULSE) 

IF  (RECETVE-ST0P<ST0P_TiME) 

ALPHA;  SF.  r—LnSE 
OTHERWISE 

FND 

OP  (LOST_PUl.SE  OR  WETl  RNF  D„pULSF  ) 

END 

re  turn 

END, 


SUBNET;  PECORD.OROP, 

REFERS  TO; 

ALPHA;  SFT.DROP 
ENTI TY_CLAS$t  ThAGE 

Entity_typfj  DROPPED.TNAGE 


EF TITY.TYPE t IF'AGE_IN  T p A C K 
EVENT:  ALLOCATE. 

TRACED  FRftMj 

OPlGINATINCi.rtEQUIWE^ENTI 

TLS.OPSRR.PARAGRAPh.  3_2_S_0_F ‘JNC  T I AL.Rf.QU  IRENE  NTs , 

REFEP»FO  RVj 

R.MET:  CC_WESPONSE 

R.NETi  RE.SP»^SE.Tp.«AnAR, 

STRUCTURE  I 

CONSUMER  ENT  I TY_CLASS  : IMAGE 
IF  ( ImaGF.I1  ..TRACK  ) 

ALPHA  t SET.OROP 
EVENT:  ALLOCATt 

OF  (OROPPED.I’-IAGE) 

EF  0 

RF  TORN 
ENG, 


SUBNET i SUM.RE turns, 

REFERS  TOj 

ALPHA:  DR3P„PULSE 

ALRha:  SE  T_SUM“EO 

alpha:  s<  IM— t'S  AGE 

DATA*  ACCffU  VTEO«F,^a  t 
TRACFO  F«ph: 

ORIGIN AT  I' ;G_ REQUIREMENT  I 

TLS.nrSPR.rARAGRAPH_3_2.4_A.FUNCTI3NAL_Rt  Gt  IRENE  NTs 
ORIGINATING,. REQUIREMENT” 

TL S.DPSpp.P a R AGP aPh. 3.  2.5_D_FUNCT I ON aL. REQUIREMENTS 
ORIGIN  AT  i”g„RE  It1 1 PEN  ENT  I 

T|  S.DPSPK.SUBSECTT(lF.3_2_<i.  FUNCTIONAL.  REQUIREMENTS, 

reeefred“by: 

W.4ET:  w A U A W.  S IJ  M H A R Y , 

STRUCTURE  ; 

CONSIDER  DATA:  ACClH  *-'TF  D.EOR 
IF  f COUNTED) 

alpha:  SU".US AGE 

ALPHA:  r>pnp.PULSE 

OR  HEITHF.R) 

alpha:  suh.USAGF 
alpha:  SE  T.SlihmE  d 
fjR  (SUMMtlJ) 

EF  0 

RF  TURN 
END, 


SUBNET:  TAl LV.RF TURNS, 

RtFERS  TO; 

alpha:  OWflP.PtJLSE 
alpha:  sft.countFd 
alpha:  sum.eneRGY 
L)  A T A i A r,  c n 1 J N T E F n (• , 

TRACF  D FRflH: 

ORIGIN  AT  ING.REQUIReF'ENT: 

Tl  3.pPSPR_PARAGRAPH.3_?_a.A_FUNr  TI ONAL.RE  QUIREMENTs 
OR I G I N A T i” G. REQUIREMENT  I 
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US_DPSPR_SIiHSECTIpK„3_2,U_FUNCTIOnal_RF:cU1REmEMS, 
Rfc.FEPWFD  RYJ 

R_.NET  J C^'-iTwni RESfJWrF-S* 

STRUT  TURF  : 

CONSIDER  DATA;  ACColNTtD_F<JW 
IF  (SUMMED) 

ALPHA;  SU*V  NER&y 
ALPHA;  DKdP.PULSE 
OF  MFITHFR) 

ALPHA;  SUM.ENFRGy 
alpha;  SET.CPUNTeC 
OF  (COUNTED) 

EKD 

RF  Turn 
END, 


SUBSYSTEM;  SSC2 

CM*), 

CONNFCTED  TP; 

I NP'. IT  ..INTERFACE*  CC_I- 
0I'TPUT_INTERFACF  l CC_oUT. 

T R A C F D from; 

ORIGINATIN  (,_  R E Q U I W E F E NT  : 

T | 3_DPSPR_SE  C T I ON_3_(>_f  LNC T ION AL_RtDUT REF  ENTS 
ORIGIN AT ING.REOUIREkE NT  J 

TL  S_DPSPR_SURSECT f of  _3_P_t_FUNCT ION AL.REQU1 REMEN TS  , 

SUBSYSTEM;  SSPEP^FL 

(*K*). 

CONNECTED  TO; 

OUTPUT, INTERFACE  | r A T A,PF  C ORD , 

traced  from" 

ORIGINAT  ING_«E3UIRf.mfnt  ; 

TLS^DPSPR^SE CTTON_3,I)_f UnCTION AL_RE.niJTRF ME  NTS 
ORIGIN at I~g_REQU  I Recent j 

TLS.DPSPW.SHMSEC  T I ')T,3_2_^_F  UNCTION  AL.REUUIREMtNTS. 

SUBSYSTEM;  SSRAUAR 

(*J*) . 

CONNECTED  TO; 

IUPUT,INTERFACE  I RADAR_CLOf.K,lN 
INPUT.INTERF ACEI  hadap,in 
OUTPUT, i (jTeRFacF  ; fapaR,OUT, 

TRACED  FROM; 

ORIGINAT I NG.REOU  I Rtf  FNT  ; 

Tl  S_DPSPR_SECTlON_j_n_MJMCTIONAL,RF.DulREMENTS 

originati"g_REduiref fnt; 

Tl  S,rjPSPR,SECTlON,3,  i_f UNCTION AL,F,EDUI REF  ENTS 
ORIGINAT  l"G_REDl'IREf  F NT  t 

H S_DPSPW,SECtIOn_3.  1,PERFORhANCE,RE(JlllRFMfcNTS, 
SYnOnVm  i CKRADMFS, 

SYnOnymi  COUPES, 

SYnOnym;  RAOJn, 
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TLS_DPSPW_RARAgRAPh_  3_P.a_B.PERF  nPMANr.fc.FEGU  I RtPENyS  # 
PATH  : 

VAL  10 AT  ION.POInT  j STARTlNf;_Pf»IMT 
ENC, 


VALlDATIflf'_pfllNT  : C2„IMAGE_HAND0VfcRf 

records: 

DATA;  H 0_ I D , 

TRACED  FROMJ 

opiginati  ^.requirement: 

Tl.  S_DPSPR_PARAGRAPh_3  ?. <J.B_PE  RFPRM  AnCE.R'ELUI  RE  RENTS  « 
referred  by: 

R.NETl  CC.RESPOInSE 

VALIDAT  I.1N~PATm:  C F_H  A N p 0 VF  R_C  0 MR  ANQ.  I NRU  T , 

valIdatior.potnt:  radar.command  'Hjtput.point, 

RECOPDS: 

D A T A { PADAR.TvPE 
UATAj  TARGET.ID 
DATAj  T R A N $ •*  I T_  S T A R T , 

TRACED  FROM: 

DECISION:  RAUAR_RtSf'UPCE_C"NTRPL_Bl 

DECISION  j RAOAR_RESf'L;prE_Ci,,NTRf'L_B? 

«P  IGjn AT  iNG.PEaiij Recent  : 

TLS_0PSPH_PARAGRAPh_3  ?_4_H.PEMF OPmanCE.PEuUIRLPENtS , 
reeermed  by: 

w.nf  t : xmit.w 

VALIDATI9N_PaThI  RADAP_CflMMAND_ril'TPUT# 

VALlDATIflt-.PIlNTl  S T A R T J N G_P PINT, 

RECOPDS: 

OATAI  WF.CHARACTErISTICS 

DAT  A i LF.NAmE 

FILE:  WAVEEORM.TABLE, 

TRACED  From  j 

ORIGINATING.REOUIRePENT  : 

TLS_DPSPR_PARAGRAPh_ 3_2_a_B_PERF  pRMANCE.PEUU I REPENTS, 
REFERRED  by: 

R.NET:  CC.RESPPNSE 

YALIHAT IflN_PATH:  r A D A P_ W A VE F ORM.PF OPER T I ES  , 

VERSION:  0RIGINAL_Pl'9LlCATl0E_DATED_Aur.iJST_l<>75t 

implemented  by: 

input. interface:  radap.in 

OUTPUT. INTERFACE : RADAR. OUT, 

VERSION:  PPL2.C PmP ILCR.L I M I T A T I nN.C OMPENS A T I , 

Implemented  by: 

R.NE  T I RESpONSE.Tn_RADAR 

subnet:  extract.measupEmEnt, 

version:  tls.dpspr, 
implemented  ryi 

ORIGInATING.REQUIReP’ENT: 

TLS.DPSPR.PARAGRAPh. 3.2. l.A.FUNC  TION A L. REQUIREMENTS 
OPlGINATING.REaUIRtRENTT 

TLS.DPSPR.PARAGRAPh.3.2_1_A_PFRF0RmanCE_REuUIREPENtS 
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SYNONVMi  RAQOUT, 


synonymi  RESPRAI), 

synonym i Tir?c*Pt 
EQUATES  TOj 

MESSAGE  » T 1.T?.COmMAKd, 

SYNONYM:  T1T2RTN, 

EQUATES  T 0 | 

ME SS AGE  I H.T2.RETLRN, 

SYnPnvmi  T3CMD, 

EQUATES  Tn | 

MESSAGE  I T3.COmmAM;, 

SYnOnym:  t 3R  Tn  , 

EQUATES  TP: 

MFSSAGE:  Ti.RETUR.J, 

VALIQATION.PATHI  C2_HA^D0VF  R.C  HmK  a NO.  I NPllT  , 

REFERS  TO{ 

VALIPATIO  N.F  0 I N T ; C2_IKaQE«.HAMPPvEP, 

CONSTRAINED  BY:” 

PrREPRMANCt.REQUI'5Er'  F NT  l EN’E RG Y^PE P_I M A(,E  , 

traced  from: 

OR IGINAT I N G.  R E Q U I R E N E N T t 

Tl S_DPSPR_PARAGRAPh_ 3_p_u-B_PERFORMANCE„PEUUlREMCNTS, 

path  I 

validat  ipn_ppi  <it  : c 2.  in-aGe.h  andover 
end, 


VALIDATION. RATH:  RADAR,COMMANn_r>LTpUT  , 

REFERS  TO: 

VALIPATIOQ.POINT  : R AOAR_COMMAQD.O|JTPIJT.P01NIT  , 

constrained  by:” 

PERFORMANCE.  RE  QU  IRENE  NT  : E N t RG Y_P  E P_  I magE 
pf  rformance.requireefnt  » pulsesIrer.seconi 
pe  rformance.requ  i recent  i radi  ate  (-.power, 
tracfd  from: 

decision:  RADAR.RESOURCE.CONTROL.pl 

DECISION:  RAOAR.RESOUBCE.CONTRPL.B? 

OPIGINATtNG.REQUIREFENT: 

Tl S.DPSPR.PARAGRAPh. 3_ ?. u.B.PE  PEPPM AnCE.PEuN I RtPENTS , 
PATH  : 

validation.poimt:  RaIar  command.outpiit.point 
END, 


VALIDATION. PATH:  RAPAP.WAVE.FORM.PrOPERTIFS, 

refers  to: 

vALIDATION.POInT:  starting.point, 
CONSTRAINED  by:” 

PERFormanCE.REQUIRf  n FNT I ENERGY.PEP.TmAGE 
PE  RFPRMANCE.REQUI»eNE  NT  I RADIATE D.PO^ER# 
TRACED  from; 

ORIGINATING. REQUIREMENT: 


**  *%•  T*  » 
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3PIGIi  4T  ING.RF QUI^E.^  J 

U S.DPSPR.P A RAQR  aPh.3_2_  l.B.FUNf  T I«naL_R{  GO  I RENE NTs 
HFIGINATING.REQUIRET'F.NT  t 

Tl  S.DPSPR.P  ARAGR  APh.  3.2.1  .B_PERFOP"Ai>iCE_P  tf-'O'I  REF  ENTS 
'5RlGINATING.RE(JUIWEl'f  ”t  ! 

TLS.DPSPP.F'ARAgBAPh.  3_  2.2.A.FUNC  TlONAl.REQO  IHt*'E  NTS 
ORIGINATING. REQUIREMENT! 

Tl  S.DPSPR.P ARAGR APH. 3_?.2„A.PE RFftRMAMCE.FEi-IJlRt RENTS 
9PIGI  NAT  INC, „REQU  IRENE  NT  t 

Tl  S_DPSPR_PARAGRaPh.3_2_2_B_FUNCTT0NAI_RE  GO' I RENE  NTS 
0 R I G I N A T I N G_  R E Q 0 1 R E *’  E N T 1 

Tl  S.DPSPR.F ARAGR  APM»3_?„2_B.PF-RFflKNANCE.FE GO  I RE  RENTS 
ORIGIN ATI  N G_ REQUIREMENT  I 

Tl S.DPSPR.P ARAGR APH_3_?_2_C_FUNr T I 0NAl._Rf Gl I RE I ENTs 
ORIGINATING. RE QUIRE* ENT  ! 

Tl  S.DPSPR.P  ARAGRAPh_3_2_2_C_PEPF0BpANCF..REuU  I REGENTS 
ORIGINATING.WEQllIRENf  NT  : 

TL  S.DPSPR.P  A RAG«aPh.S_?_2_D.F'JNCT  I 8N‘Al_HF  GO  IRE*'E NTs 

trig i nat ing.requ irene” t7 

Tl  S—DPSPR— PARAGRaph_3_  2.2.G.  PERFORMANCE.  f-EGU  IRE  RENTS 
ORIGINATING. REQUIPeRFNtT 

Tl S_DPSPR.PARAgRaPh.3_2.2_E.FUNc T I ON AL.REQU I RENE N Ts 
ORIGINATING.REQNIRtNENT” 

Tl S_DPSpR. PARAGRAPH. 3_ ?_2_E_PE RF ORR A NC E.PENU I Rt NE NTS 

ORIGIN AT i”g_REQUIBE* FNt7 

Tl  S_DPSPR.PARAGR4Ph.3_2_  S.A.FUNT  T IONaL.RE  GIjIHEN'FNTS 

opiginating.requirerent’ 

Tl  S_r.'PSPR_PARAGRAPH_3_?_3_A_PERF0RMANCE.FEU'lRtRENTS 
OPIGINAT ING.REQUIReNFNt” 

Tl  S_r>PSPR_P4RA&RApH_  3_?_  3_B_F  UNC  T 1 OmaL.RF  GUI  N E M E NTS 

originating. requirf”f~t7 

Tl S_pP  SPR_P  ARAQRaPh. 3_2. 3.B.PF  RF ORm a nC E.PENU I RENE  N T S 

OPIGINAT i”g.REQU I Re”f N t7 

TL  S.DPSPR.P araqRAPh. 3_ 2.3.C.FUNC  T IONAL.RF GO  I REPENT  s 
ORIGINATING. REQUIReNFNT! 

TL  S.DPSPR_P4RAC,RAPh.  3_?_3_C.PERPORPAiiCE.RFf,’IJlRERf  NTS 
ORIGINATING.  RECJUIBEf'FNT7 

Tl  S.DPSPR.P  AR  A GRAPH.  3_2.3_D.FUMf  T I OflAl_RF  QUIRE*1  ENTs 
OPIGINAT  i”g_REQUIRe*’f~t7 

Tl  S.DPSPR.P  ARAqRAPh.  3_2_3_0.pERF  CRN  A nCE.RF-OU  i Rt*  E N T S 

3piginati”g.pequire*e nt7 

Tl  S.0PSPR_PARAGPAPh.3_2_3.E_FUNCTI0NaL_RF  QUIRE*>ENTs 
OPIGINAT  ING_REQI;1RE''FNt7 

Tl  S.DPSPR.P  arARRAPh.  3_?_3_E_PERF0RMANCt.PENlJIRLE'ENTS 

OPIGINAT i”g.require”e”t7 

T l S.DPSPR.P  A R AGP  APh.  3_?_3.F_FUNC  T I ON  AL.RF.CO  IREBENTS 
OPIGINAT  i“g_REQUIPE,,FNt7 

Tl S.DPSPR.P AR AGP APh. 3_?_3.F. PERFORM ANCE.PENU1 REGENTS 
OPIGINAT  I NG.PEQI' I RECENT  I 

TL  S.DPSPR.P  AP  AGP  APh.  3_?_'3_G_FIHC  T I 0NAL.RE  001  FEME  NTs 
OPIGINATING.REQUIRE*  fnt7 

TL  S.DPSPR.P  AR  Af,R  APh.  3_ 2_3_G_PERF0RMAnCE_PEoUIREFENTS 

OPIGINAT i”g_REQUIRE* ENt7 

tl  S.DPSPR.P A P AG R APh. 3_?.«_A_FUMf T I ON Al.RF QO IRENE  NTs 
OPIGINAT  I NG.RF.QO  IRE*  TNT  ! 

Tl  S.DPSPR.P  AR  A graph.  3.  2.  4.A.PF  RF  ORM  A nC  E.RF  UUIRENFNTS 

OR  I GI NAT ING.REQUIRE* Fm7 

Tl  S.DPSPR.P  AR  A GRAPH.  3_?_(J.B.FiJNC  TIONaL.RI  QO  I RENE  NTs 
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flPIGI^ATIiMG.»E3UIRt>tKTt 

TlS_[)PSPfv_R4RAGR  aPh_  i_2_4_H_PERF  oRMANCE_RE(  UIPt^t^TS 
ePlGINATl'MG.WEaUIRE^ENT » 

T l S_DPSPR,PAPAGWAPH_3_?_b.A_Fi)rjr  TI°NAL_Wt  GU I P E *F  N T s 
OP IGINAT  ING.PEQUIPf.KEKtT 

Tl  S-DPSPP-PAPAGRAPh„3_?_?i-A_PEWF  ORMANf  E.FEUtJlREF'E^'TS 
9RIGINAT ING.^EOUIRe^EKtT 

TLS_nPSPR-PAP4GPAPH..3_?_e5_H_FU'JCTI9NAL_RF  GU  l RECENT  S 
OPIGINATING.REQUIRe^ENtT 

TLS.OPSPP.PARAGRAPh.3  ?_5_H„PERF ORM ANCE..PEGII  I REF E N T S 
9RlGiNATl”G_REaUIREF E~t” 

TL  S_DPSPW.PARAGH  APH_3_p_b»C_Fti:'lCTT9NAl_RF  QHlRtMMS 
BRIGINATING.REOUIRe^EntT 

TL  S_OPSPf<_PA  PA  GRAPH.  3_  ?_b_C_pE  RF  9K^anCE-.REwUIPL^F^TS 
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